Authorization

[findapollo]

Ok...I've been trying to find a way to bypass the pop-up of the browser for basic authorization by setting the right $_SERVER vars or header(); lines to no avail. The only way I've been able to bypass is with this:
header("Location: https://name:[e-mail]/securefolder");

My main concern with this is how secure is the request. Does the location with the name:pass get sent at all over an insecure connection? Also, if I have have a form that POSTs the name/pass to a page that basically just redirects as above, should that be under SSL too so nobody can see the POST vars?

Oh, and if anybody does know how to do this a better way, please let me know.

Thanks,
Findapollo 😃

[mtimdog]

Btw, Microsoft just updated IE so that opening a page like
https://name:[e-mail]/securefolder
no longer works because of a security glitch.

[findapollo]

Btw, Microsoft just updated IE so that opening a page like

https://name:[e-mail]/securefolder/

no longer works because of a security glitch.

Great news, NOT!

So there has got to be a way to set the right variables or headers to prevent the log-in pop-up. Does anybody know how this can be done?

findapollo

(p.s. i know this is the wrong forum to ask this, but it doesn't have to be PHP, it could be ASP or CGI too)

[Poolie]

Can you not just use sessions ? and check for the session_id() etc etc etc ? or am i totally of course here LOL 🆒

[findapollo]

Can you not just use sessions ? and check for the session_id() etc etc etc ? or am i totally off course here LOL

From my limited knowledge of sessions, I don't think so. If I'm wrong, someone please tell me.

Findapollo

[kid_c]

Damn, I just posted a new thread asking a pretty similar question =)

I haven't been able to do it, but in my case sessions are not the answer as the load is way too heavy compared to the method I currently use.

I just thought it would be nicer if my current method (my own custom sessions), would be invisible, and setting $_SERVER[] vars into the browser seems to be ideal.

[mtimdog]

It seems to me you're going about this a$$-backwards.

Why not have the login-page redirect to a login on the https (so you take advantage of using ssl during login). That way, you don't have to worry about the hokey pokey.

If you need the login to be cross-domain (http, https)...you can store the login info in a database with the a random session id(not the one generated by php because that will probly change when you change domains), ip, etc...then either use a cookie or put the session id on the end of the link to link between http and https.

[findapollo]

Ok everybody, I think we're losing sight of the goal here. We want to be able to design our own log-in page (and of course it would be under SSL) that redirects the user to a page where they can download files that contain sensitive information. Correct me if I'm wrong, but bypassing the .htaccess file is never going to be possible with PHP because of ths simple fact that it is server-side programming. The authorization header is in the request that comes from the browser, and the only way you could control that is with a client-side programming language like an ActiveX control or mayba Java. So, aside from teaching yourself ActiveX, I did find a solution. It involves using PHP as a gateway to serve up files that are outside the web_root/ folders. If you're interested, I found the article on Zend.com:
http://www.zend.com/zend/trick/tricks-august-2001.php
So, it's too bad that this client is not satisfied with just putting their password in the browser pop-up and they want a single log-in page, because for a few clients the .htaccess method would be so much easier.

With all that said, I would like to respond to mtimdog:

It seems to me you're going about this a$$-backwards.

Who died and made you god?

Why not have the login-page redirect to a login on the https (so you take advantage of using ssl during login). That way, you don't have to worry about the hokey pokey.

We never said we wouldn't be using SSL from the start, and the "hokey pokey" you so elegantly speak of is so they don't have to log-in more than once.

If you need the login to be cross-domain (http, https)...you can store the login info in a database with the a random session id(not the one generated by php because that will probly change when you change domains), ip, etc...then either use a cookie or put the session id on the end of the link to link between http and https.

Thanks for the tip on using your own session ID, I'll remember that. We decided that sessions WILL NOT work though, because we're not protecting just PHP pages, and unless you know how to verify a session in an MP3 or Word DOC, having a session would be useless.

I don't care how many posts you have made, you should think before you type because you may or may not be a PHP pro, but saying things that are only intended to make others feel stupid only makes you look stupid.

Findapollo

[mtimdog]

Sorry if my opinions offended you, they were not meant to be.

Also findapollo, it helps if you tell us the "goal" from the get-go. I'm sure you did in another thread, but I must have missed it.

If you had posted earlier that you were logging them in to download a file, I'm sure someone in the community would have offered a similar suggestion like your solution.

Keep plugging along, it'll eventually work.

[findapollo]

Hey man, I'm sorry for kinda going off on you. I do appreciate your posts as both the fact tha MSIE won't allow uname:[e-mail] redirection and the fact that a sessionID could be different whether you're on http: or https:. Oh, and I'm sorry for maybe reporting you to the moderator. I think it was the a$$-backward comment. It was a bit too condescending. Good advice can be given without belittling.

It's all good man, peace.

[mtimdog]

After seeing what you're really trying to do, I stand by my backward comment. btw, attacking people that are trying to give you constructive criticism is not helping yourself. How reluctant will I be to offer you advice down the road when you need more help?? (not that there aren't millions of others more capable than me to help you out there). I perceived my words as being toned-down....I was talking to you as if I was talking to a good friend, but you have become defensive at nothing. As far as I can tell, i'm not god. You never implicitly said you were using ssl from the start. I deduced from your words that you were going from http to https incorrectly. I define hokey-pokey as loggin in at domain1.com, redirecting with username/pass in header to domain2.com to download files. Now, after knowing that everything is under ssl (and deducing that it's probly the same domain)...I can clearly say that this was not a case of the hokey pokeys....just not enough info by the author.

Oh, and I'm sorry for maybe reporting you to the moderator

maybe??...either you did or you did not. Whatever, my time is more valuable than helping people, then being accused of this or that. Now, it's off to H&R block to sift through my taxes. There are only 10 things you can count on in this world, taxes and death. (come on, think binary).