I had a pretty good homebrew login setup on my site using both a local registry and working with Facebook, Google, and Twitters 3rd party auth tools.
But now that I've secured the site with an SSL cert it seems to have been borked in an odd way. As near as I can tell, the Sessions won't take the first go around, but try again and the session kick in, it was working fine before the SSL switch over, so I feel like I'm missing something related there.
Is there something I should be paying attention to in particular? Some sort of common misstep for someone that has never used PHP sessions in an SSL environment perhaps?
Turns out in this case, watch out for missing "www" at the beginning of redirect URLs.
Related
I have a use case where I need to be able to access my site from the local server. Specifically, it's for a HTML-to-PDF export of parts of various pages, but this would be nice for testing parts of the website as well.
The problem is that we have a login splash page, which needs to be dealt with before I can access any parts of the website. It would be really nice if I could just call a command "wkhtml2pdf 'localhost/[myurl]'" and have it PDF some stuff, but it hits this splash page.
Is there some way that I can perma-persist just one single session on the server? Or enable login-less access from localhost? Or could I just add a new Apache entry that accesses our site, whitelists only localhost and somehow circumvents the login?
What's the best solution?
You can pass your session cookie as parameter in wkhtml2pdf to solve your problem.
You can also execute it from a php file like this.
exec("wkhtmltopdf --cookie '{$cookieName}' '{$cookieValue}' http://example.com");
Soliciting feedback on this solution now:
I whitelisted localhost via $_SERVER['REMOTE_ADDR'] in the login scripts to bypass the usual user authentication and get an automatic localhost-user login. The server is running, however, on a university LAN, so the LAN maybe really big, possibly enabling bidirectional TCP spoofing.
Should I be worried about this, or does someone need admin rights on the routers or something? I trust the IT folks, but not others.
I realize that this sounds like a separate question, but I feel that security relates to whether or not this is a good solution.
I've recently done my first wordpress site that is using an SSL license. I've noticed it comes up as secure but with errors. In the details it says the following.
Your connection to www.kluemperinsurance.com is encrypted with
obsolete cryptography. However, this page includes other resources
which are not secure. These resources can be viewed by others while in
transit, and can be modified by an attacker to change the look of the
page.
The connection uses TLS 1.0.
The connection is encrypted using AES_256_CBC, with SHA1 for message
authentication and DHE_RSA as the key exchange mechanism.
I'm not familiar with any of this so I went to an SSL error checking site to find out what is causing the errors and every page comes up with this.
Pages with unsecure content: https://www.kluemperinsurance.com/ ?
http://ajax.googleapis.com/ajax/libs/webfont/1.4.7/webfont.js
http://feedburner.google.com/fb/a/mailverify
I've tried to figure out how to fix these two issues but I haven't had any luck so far. I'm not using a feedburner of any kind that I am aware of. No plugins being used either. For the webfont issue I followed the instructions from this link and it did not seem to help.
Am I at least on the right track here? What do you suggest I look for instead? Do you know how to fix it?
You have http links on a site which is being served as https. Change any links such as http://ajax.googleapis.com/ajax/libs/webfont/1.4.7/webfont.js to their secure version if available. Normally this will simply be changing http:// to https:// or // but you will need to check if your third party providers support secure urls, and if so what they are (some might use the hostname ssl instead of www for example).
I used to work for a bank, that had a very cool feature in it's intranet. Once you logged in your computer, there were global variables set in PHP through Apache, and they contained the identity of the user that was logged on on the computer. Now I'm at a new job, and I'm wondering, how this thing worked! I would like to implement this kind of thing once again.
What I'm working with here:
FreeBSD server, version is unknown to me.
Apache 2.2 web server
PHP 5, some custom compilation, that for various reasons, I can't upgrade or modify.
MS AD
All of the users logging on to their computers are using active directory, all are in the same domain.
What I used to have was something like this:
echo $_SERVER['username']
which would print the username of the user currently logged in.
Could someone explain, how this could be done?
P.S. If any of my server settings are not what is required, say so, because then I will have a reason to ask the bosses to give me one of my own, with more control.
There's lots of ways this might be implemented. However a lot of them depend on having control over the client as well as the server.
Obvious sources of data include:
NTLM
Client side certificates
The Ident protocol (not very secure without the encryption extensions)
A long lasting cookie (again, not secure)
HTTP authentication methods
However none of these explain how the value appeared in the session - this must have been implemented within the PHP code.
So without knowing how it was implemented at your previous site we can't tell you:
Whether it was secure and correctly implemented
how to replicate the behaviour
Given your resource list, while it would be possible to implement authentication based on direct LDAP calls, passing the username and password through your application, I would strongly recommend using (e.g.) openId - but restricting the providers to just your openid provider - which would use the MSAD as the backend.
I did not understand correctly the question, so I edit my post...
you could use apache auth, you can make auth by ip's or hostnames
http://httpd.apache.org/docs/2.0/en/howto/auth.html
Initially I had the issue reported in this question.
Now, what I noticed is that there are some browsers that accept the password, and there are some which don't. Difference? For some reason the cookie is generated when I log in into the Administration module, but it isn't when I write down the password to access the page, forcing it to simply reload.
I can see the cookie created for the log-in, but I can see none for the password-protected Page.
These happens on Internet Explorer, both version 7 and 8; only on some machines, though, but most of them fail this. I already tried white-listing the URL, and even letting it accept ALL cookies, to no avail.
What may be the cause? If perhaps it's got something to do with question above, please help me!
Thanks in advance.
PS: If you know of another, cookie-free method to make a simple authentication, please link me to it. Thanks. Oh, and by the way, this is inside an Intranet with static, class C IPs.
Assuming you're on an Apache server, consider this authentication module for Wordpress that allows for a far more flexible approach:
http://wordpress.org/extend/plugins/http-authentication/
This module allows you to Bypass WordPress' normal authentication and use Apache's authentication instead - So pretty much any auth you'd like to use.
You can find more information on Apache Authentication methods here:
http://httpd.apache.org/docs/1.3/howto/auth.html#database
I've pointed at the database section as I'm assuming you'll want to use a database to authenticate.
I'm vaguely aware that on a computer joined to a domain IE can be asked to send some extra headers that I could use to automatically sign on to an application. I've got apache running on a windows server with mod_php. I'd like to be able to avoid the user having to log in if necessary. I've found some links talking about Kerberos and Apache modules.
http://www.onlamp.com/pub/a/onlamp/2003/09/11/kerberos.html?page=last
https://metacpan.org/pod/Apache2::AuthenNTLM
Since I'm running on Windows it's proven to be non-trivial to get Perl or Apache modules installed. But doesn't PHP already have access to HTTP headers?
I found this but it doesn't do any authentication, it just shows that PHP can read the NTLM headers.
http://siphon9.net/loune/2007/10/simple-lightweight-ntlm-in-php/
I'd like to be able to have my users just point to the application and have them automatically authenticated. Has anyone had any experience with this or gotten it to work at all?
UPDATE
Since originally posting this question, we've changed setups to nginx and php-fcgi still running on windows. Apache2 and php-cgi on windows is probably one of the slowest setups you could configure on windows. It's looking like Apache might still be needed (it works with php-fcgi) but I would prefer a nginx solution.
I also still don't understand (and would love to be educated) why HTTP server plugins are necessary and we can't have a PHP, web server agnostic solution.
All you need is the mod_auth_sspi Apache module.
Sample configuration:
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIDomain mydomain
# Set this if you want to allow access with clients that do not support NTLM, or via proxy from outside. Don't forget to require SSL in this case!
SSPIOfferBasic On
# Set this if you have only one domain and don't want the MYDOMAIN\ prefix on each user name
SSPIOmitDomain On
# AD user names are case-insensitive, so use this for normalization if your application's user names are case-sensitive
SSPIUsernameCase Lower
AuthName "Some text to prompt for domain credentials"
Require valid-user
And don't forget that you can also use Firefox for transparent SSO in a Windows domain: Simply go to about:config, search for network.automatic-ntlm-auth.trusted-uris, and enter the host name or FQDN of your internal application (like myserver or myserver.corp.domain.com). You can have more than one entry, it's a comma-separated list.
I'd be curious about a solution that uses OpenID as a backend (of sorts) for this... I wasn't seeing anything that would hook into ActiveDirectory directly when I googled (quickly). However, it could be pretty painless to implement over plain HTTP(S) (you'd be an OpenID provider that checked credentials against your local AD). In a best case scenario, you might be able to just add a couple classes to your app and be off and running -- no web server modules required. There is a lot of open source code out there for either side of this, so if nothing else, it's worth taking a look. If you exposed the backend to the users (i.e. gave them OpenID URLs), you'd have the added benefit of them being able to log in to more than just your internal sites using these credentials. (Example: Stack Overflow.)
As an aside, I'd be against making it so that Internet Explorer is required. I'm not sure if that is the goal from the way you wrote the question, but depending on your IT environment, I'd expect people who use Firefox or Safari (or Opera or ...) to be less than enthusiastic. (You're not developing against IE first, are you? That's been painful whenever I've done so.) This is not to say that you couldn't use this feature of IE, just that it shouldn't be the only option. The link you posted stated that NTLM worked with more than IE, but since I don't have any experience with it, it's hard to judge how well that would work.
I had a similar problem which I needed to solve for my organization.
I was looking into using adLDAP.
There is some documentation on the site for achieving seamless authentication with Active Directory too.
One option for you is to use CAS (central authentication service).
It has php client library.
How-to link to MS Active Directory: http://www.ja-sig.org/wiki/display/CASUM/Active+Directory
You would require Apache maven 2 though.
For IIS/PHP FCGI, You need to send out an unauthorized header:
function EnableAuthentication()
{
$realm = "yoursite";
header('WWW-Authenticate: Digest realm="'.$realm.'",qop="auth",nonce="'.uniqid().'",opaque="'.md5($realm).'"');
header("HTTP/1.1 401 Unauthorized");
exit;
}
You can then get at the username with:
$winuser = $_SERVER["REMOTE_USER"];
I then make sure the $winuser is in my database of allowed users.
Be SURE and test this under a non-privileged account. When I first installed this I tested it and it worked fine, but later when a standard non-server-admin user tried it this failed. Turns out some of the temporary directories need to have permissions changed for guest users. I can't recall the exact settings.