[cfaussie] RE: cflogin

[Phil Evans]

Thanks Spike.   I'll give it a whirl and see what happens.   Phil. ----- Original Message ----- From: spike To: CFAussie Mailing List Sent: Tuesday, June 17, 2003 6:33 PM Subject: [cfaussie] RE: cflogin When you turn on secured authentication in IIS, it will fire up a challenge-response dialog box to any unauthenticated user. In order to know whether a user is authenticated or not, it checks the http headers that were sent with the request. On the first request to a site, a browser will not normally send authentication details in the http headers, so you get the challenge-response dialog box. IIS puts the username and password in to the HTTP headers for the response and encodes them to base 64. When the browser sends back a subsequent request, it returns the same header value for authentication. I'm not 100% sure if the same headers are sent when you use integrated domain authentication with IIS, but it's certainly a possibility. If you try the code I posted earlier, you should be able to figure out pretty quickly whether the username and password are being sent. If they are, they will be the domain username and password for that user. You will almost certainly be able to get the username which you can then use in cfloginuser to maintain the user's login state in your CF app. The default in IIS is to encode the headers as base64, but you can increase the encryption level which would render the technique I described earlier useless for decoding them. Hope that helps a bit. Spike Phil Evans wrote: Hi Spike,   Now you've got me really confused.   I thought I was asking "how do I pick up the username that logged in to the windows session", but given that there's a password that I can also pick up then that doesn't sound real secure???   What username / password are you talking about?   Thanks, Phil.       ----- Original Message ----- From: spike To: CFAussie Mailing List Sent: Tuesday, June 17, 2003 4:39 PM Subject: [cfaussie] RE: cflogin You should be able to read the username and password out of the HTTP headers that are sent to the server: getHTTPHeaders() Somewhere in there you will find the encoded username and password. They are encoded to base64, so you should be able to decode them without too much trouble using this code: <cfscript>   encoder = createObject('java','coldfusion.wddx.Base64Encoder');   cleartext = encoder.decode(encodedheader); </cfscript> That should give you username:password as clear text providing you have the right http header. Also, this will only work if your webserver is using simple encryption. I don't have a set-up I can test this on right now, but hopefully you get the idea. Spike Phil Evans wrote: I've always just written my own, with the username saved in a cookie, and they enter the password each time. Works fine, but I've always wondered about how to get integrated windows authentication? I'd prefer to avoid cflogin if possible.   Any tips?   Thanx, Phil. ----- Original Message ----- From: spike To: CFAussie Mailing List Sent: Tuesday, June 17, 2003 4:07 PM Subject: [cfaussie] RE: cflogin The main advantages are: It gives you a single sign on mechanism for flash, integrated windows authentication and ColdFusion It provides you with a standard mechanism for specifiying the roles to which a user belongs and a native function to test for role membership. It provides you with a standard mechanism to get the username of the logged-in user. The main disadvantages are: It gives you a single sign on mechanism which provides a wider target for script kiddies It puts the username and password into the authentication cookie without encrypting them. It's a session cookie, but it's a potential problem nonetheless. It does not provide any standard mechanism to tie roles to permissions, so you usually end up either hard coding permissions per role, or building your own mechanism. On balance, if you're comforatable writing your own code and you're sure that your own login process is secure you might as well avoid cflogin. If you're not 100% sure that your own login process is secure, it is probably worth taking a second look at cflogin. my 2c Spike Mark M wrote: I am probably going to start a big hoo haa saying this, but I personally dont see the point of CFLOGIN apart from the user roles within CFCs. That is the only functionality it provides. Corrections please? I'll second that one. How hard is it to go 'session.userloggedIn = true' Ouch... my pinky hurts :oD Mark ----------------------------------- [EMAIL PROTECTED] ICQ: 3094740 Safe From Bees [www.safefrombees.com] --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/