I have a directory that is password-protected via apache. I have a "pretty" login so that users can enter their username and password from the web site instead of the usual/ugly apache prompt. Basically, PHP (but it doesn't matter what language) takes the form input and redirects to the destination using a format like this:
Everything works perfectly in Firefox, but in Internet Explorer, I get the following error:
"Windows cannot find 'http://username:email@example.com'. Check the spelling and try again."
What gives? Thanks for any help!
P.S. The PHP is irrelevant. I get the same result if I bypass that step and just enter the redirect URL directly into the browser.
You are aware that putting credentials in the url is really horribly insecure.
Haven't bothered to look but my money would be on IE stomping on this practice to help ensure security.
Yeah, I'm looking for a better way, and you're absolutely right. Internet Explorer no longer supports usernames/passwords in URLs, even over HTTPS. Thanks. I can't seem to figure out whether or not PHP can put the username and password in a cookie that Apache would recognize in order to bypass a second login (.htaccess). Do you know? Nothing I've been able to find seems too clear on the subject, but maybe it's just me...
Sorry, no idea -- really avoid apache and PHP when I can these days . . .
Hi look at storing your hashed passwords in PHP using sessions. You can carry over and verify the password hash on ever page
ServerStorm, I'm confused. I already store the passwords in sessions so that a successful login carries to every page, but I don't know how to make it so that the username and password are read by Apache when the user navigates to an area that has its own, separate security (though the username and password will be the same as those used by PHP in this case). I'm trying to avoid making the users enter their username and password twice. Thanks again for any help.
ServerStorm hit the mark with sessions. However, you will have to read and write sessions as your visitors proceed throughout your website. More security in particilar areas? Encode the visitor's permissions in the session and you don't need add'l Apache logins. I've done that in the past and it works a treat.
Again, I'm already reading and writing sessions. The problem is that I don't control the area that has the Apache login, and it can't be changed. But the client wants its users to be able to enter their username and password on the home page of their web site and have it redirect them to the area that I don't control (it's actually a subdomain) without having the Apache authentication popup kick in (because they'll have already entered a valid username and password).
Sorry, your client does NOT understand how servers work. You'll have to use a healthy of "unobtainium" to resolve HIS problem.
Could you reverse proxy the content using a PHP script that could pass the credentials?
Note this is all pretty moot if the apache server using http authentication isn't running ssl anyhow.
In any case your client probably needs a reality check. Or at least a visceral demo of how easy it is for a user / pass to slip out this way.
As wwb_99 says you would need to have the main-site that gets passed the credentials to use ssl (https). If this was the case, you could use a post widget that posts the credentials to the main-site. To get this to work though, you will need to change the main-site page to accept this, and given that you said you can't change the other site, then I don't know if this is possible?
Also, no matter what method is chosen, it is true that it is very easy to steal passwords without some sort of proxy, ssl and encrypted passwords, so don't do any method until you know that it is secure.
I like @wwb_99's idea about showing a visceral demo :tup:
This topic is now closed. New replies are no longer allowed.