Re: mp2: architectural question re authentication handlers
Quoting Carl Brewer [EMAIL PROTECTED]: Forgive me for asking yet another fundamentally basic question. I'm cutting a web app over from PHP to mod_perl 2, and am wondering how 'best' (for which there are many flavours ...) to handle authentication. At present I've knocked up a site that does auth via a form and state tracking with Session.pm. The form checks usernames passwords against a MySQL database, and the state is maintained by Session. This seems quite logical to me, coming from essentially a CGI background, but the discussion of handlers around here makes me believe there's a better way? I would highly recommend the Eagle book if you are looking to move beyond CGI when using mod_perl. I know that you are looking at mod_perl2, and the Eagle book does not cover mod_perl2, but it will give you great insight into how mod_perl and Apache works. And lucky for you, since you are interested in Authentication and Authorization, that chapter happens to be available online. http://modperl.com:9000/book/chapters/ch6.html Also checkout the great documentation available at http://perl.apache.org/ If you want a good example of how to implement Authentication and Authorization in mod_perl, then look on CPAN for the man Apache::Auth* modules. I have used Apache::AuthCookie in many projects and it has relatively good documentation. You will also find tonnes of info on Authentication if you search the mailing list archives. I see threads here discussing the use of handlers, which I don't really understand how they fit into the picture, they seem to my poor understanding to be a hardcoded chunk in httpd.conf, for handling authentation/state. Is there anywhere a dumb beginers guide to how this works? The easiest way to explain it is to just look at Apache's Basic Authentication support at first. The one where the browser pops up a window and you type in your username and password, and Apache authenticates the user for you before it will allow the CGI script to be executed or the html file to be downloaded. You configure that in httpd.conf or in .htaccess files, telling Apache who has access to specific files and directories. This is just your standard access control stuff. Now imagine that you can use that same core functionality in Apache, but write the routines yourself in perl. And instead of the ugly login popup you can instead create an HTML login page. Do they set environment variables or something that a script can then look for that the script can be sure is legit? Yes, they set the HTTP_USER variable to the users login when a user is authenticated. But your script doesn't need to even worry about that, because Apache won't execute the script unless the user is authorized. So if the script is executing, then the user is authenticated... for now I'm continuing with my form based authentication, but is there a 'better' way? And if so, what makes it better? The biggest benefit I find is that you can separate your authentication code from the rest of the code. With an Authentication handler, your CGI script or content handler will never even be executed unless the user has been authenticated. Also, how would you use a CGI based authentication scheme to limit access to a static HTML file, or an image? It can't be done cleanly. But with Authentication handlers, you can hook them to a Location or Directory directive or even a Files directive in the httpd.conf file. So you can protect an entire directory with ease. Cheers, Cees
Re: mp2: architectural question re authentication handlers
Cees Hek wrote: [chomp] Thanks Cees, that's exactly what I needed :) My stuff is all completely generated by scripts where I need access control, but I certainly see the use for controlling static entity access. Carl
mp2: architectural question re authentication handlers
Forgive me for asking yet another fundamentally basic question. I'm cutting a web app over from PHP to mod_perl 2, and am wondering how 'best' (for which there are many flavours ...) to handle authentication. At present I've knocked up a site that does auth via a form and state tracking with Session.pm. The form checks usernames passwords against a MySQL database, and the state is maintained by Session. This seems quite logical to me, coming from essentially a CGI background, but the discussion of handlers around here makes me believe there's a better way? I see threads here discussing the use of handlers, which I don't really understand how they fit into the picture, they seem to my poor understanding to be a hardcoded chunk in httpd.conf, for handling authentation/state. Is there anywhere a dumb beginers guide to how this works? Do they set environment variables or something that a script can then look for that the script can be sure is legit? Or am I completely missing the point? Do I need to buy a book? It seems really bad to go hacking into httpd.conf, but maybe that's just my old-school conservatism? for now I'm continuing with my form based authentication, but is there a 'better' way? And if so, what makes it better? Carl
Re: Authentication handlers
On Mon, 5 Mar 2001, Daryl Campbell wrote: Cees suggestion seems to unlock part of the browser behaviour puzzle that we are trying to solve to meet the following requirements for a PerlAuthenHandler: *URL based session handling if cookies not enabled, *LDAP authentication, *Force reauthentication if given inactivity period passed, *Maintain state information in main memory, no DBI store required. So now our session state information is "Time_last_accessed and Next_realm", or generate the realm based on current time if inactivity period lapsed. Assuming that we are sending an AUTH_REQUIRED when inactivity period is lapsed. Forget about Realms and AUTH_REQUIRED headers if you want to do the above. You can use Apache::AuthCookieURL to handle passing session IDs to and from the browser (Requirement #1). You will have to override 2 functions (writing them should be very straight forward): authen_cred() which will verify the credentials passed from the login form (using LDAP in your case, Requirement #2) and create a new session for them. And authen_ses_key() which will verify that the users sessionID is still valid, or if it needs to be expired (Requirement #3, if you return nothing from this function, Apache::AuthCookieURL will redirect the user to the login page automatically). Now you should have a mechanism that handles your session keys for you, but you still need to store the session data somewhere. I have used Apache::Session with good success, but there are others available as well. I would be careful about storing session info in memory (Requirement #4). If your server gets hit hard, you could very quickly run out of memory. You would have to put some memory limits im place, and that means saving inactive sessions to disk. It really depends on your setup, and how many concurrent users you are planning to have. 1. If you aren't going to have many users, your machine won't be that busy, so you might as well save to a database. 2. If you are going to be very busy, you will probably have too many sessions active to be able to store them in main memory. 3. If you are really busy, but you don't have much to store in the session, you might as well encrypt the data and send the info in the cookie/URL instead of passing the sessionkey. But if you still want to do it, you could use IPC::Shareable (an old version of Apache::Session supported this module, but it has been removed since). There is also IPC::Cache and probably others as well. Go easy on me, it's my first mod_perl posting but have been chewing on the mod_perl guide, eagle book, and the mailing list archives. Well, this is only my third message to the list ;) -- Cees Hek SiteSuite Corporation [EMAIL PROTECTED]
Re: Authentication handlers
From: Erdmut Pfeifer [EMAIL PROTECTED] Subject: Re: Authentication handlers On Mon, Mar 05, 2001 at 10:28:15AM +1100, Sisyphus wrote: - Original Message - From: Pierre Phaneuf [EMAIL PROTECTED] To: modperl [EMAIL PROTECTED] Sent: Monday, March 05, 2001 9:29 AM Subject: Re: Authentication handlers Cees Hek wrote: So instead of storing a y/n in the database, store a unique string that is used as the realm, and clear it when they log out. Now everytime you send the Authenitication required header, send the unique realm for this user that you stored in the database, and if it doesn't exist, generate a new one. Good one! The only bad thing I see is that the realm is visible in the dialog box the user see, isn't it? Seeing a random string might be a bit unsettling for the user, but there is no technical reason for it not to work. -- Pierre Phaneuf Systems Exorcist Hi, Are you guys sure about this ? I just tried it out and it doesn't work for Apache1.3.12(win32) on win 98. I visited a page in a 'basic authentication' protected directory, then changed the name of the realm from 'htdocs access' to 'htdocs' but was still able to access other pages in the same directory without being hit for username and password. I tried hitting the back button and 'refreshing', and I also visited another site in the interim. All to no avail. Hi, there are two things to consider here. First, the server really has to send the AUTH_REQUIRED + realm; second, the browser does have to honor that authentication request by asking the user for a new name/password. Typically, servers are set up not to send the AUTH_REQUIRED response code, when the browser already is sending a valid username/password combination. And that's where browser caching comes into play: having queried the user once for username/password, the browser associates it with that specific URL and automatically resends it for each subsequent request to that location (which usually makes sense as it avoids another round trip to the server). Now, what happens if the server is configured such that it sends an AUTH_REQUIRED, even though it did already get the basic authorization header? Well, as so often, it depends on the browser. Netscape, for example, does pop up a dialog box, asking for re-authentication, while IE simply resends the same old username/password combination again. Thus, in IE you don't get a chance to enter any new credentials for a certain location which you've already visited in the current browser session. M$ obviously thought that this would never make sense ;( (it effectively means that you have to restart IE, if you need to login anew...) I haven't yet tested this issue again to see what happens when bringing the "changing realms"-idea into play. Maybe an AUTH_REQUIRED + _new_ realm would even convince IE to allow re-authentication... ;) Erdmut Hi, Cees suggestion seems to unlock part of the browser behaviour puzzle that we are trying to solve to meet the following requirements for a PerlAuthenHandler: *URL based session handling if cookies not enabled, *LDAP authentication, *Force reauthentication if given inactivity period passed, *Maintain state information in main memory, no DBI store required. So now our session state information is "Time_last_accessed and Next_realm", or generate the realm based on current time if inactivity period lapsed. Assuming that we are sending an AUTH_REQUIRED when inactivity period is lapsed. Now what PerlAuthenHandler's do we build on that come closest to this design? Apache::AuthCookieURL and extend to include inactivity modifications + memory management like in Eagle book pg. 222 Apache::AuthenLDAP and use them together as stacked handlers. Go easy on me, it's my first mod_perl posting but have been chewing on the mod_perl guide, eagle book, and the mailing list archives. -- Daryl Campbell The magician tried to blame it on the rabbit, Athabasca Universitypulled her out of the hat couldn't make her disappear (780) 675 6379 ...never more blind than when looking at ourselves [EMAIL PROTECTED] Bob Kemmis, Kemmisutra
Re: Authentication handlers
On Sat, 3 Mar 2001, Kiran Kumar.M wrote: hi , i'm using mod_perl authentication handler, where the user's credentials are checked against a database and in the database i have a flag which tells the login status (y|n), but aftr the user logs out the status is changed to n , my problem is that after logging out if the user goes one page back and submits the browser sends the username and password again , and the status is changed to y . Is there any means of removing the username and password from the browsers cache. I'm assuming you are using Basic Authentication here... I haven't used Basic Authentication in a couple years now, but I seem to remember that you can specify a 'Realm' in which the username and password is valid. If you change this realm when the user logs out, then they will be prompted for their username and password again. So instead of storing a y/n in the database, store a unique string that is used as the realm, and clear it when they log out. Now everytime you send the Authenitication required header, send the unique realm for this user that you stored in the database, and if it doesn't exist, generate a new one. -- Cees
Re: Authentication handlers
Cees Hek wrote: So instead of storing a y/n in the database, store a unique string that is used as the realm, and clear it when they log out. Now everytime you send the Authenitication required header, send the unique realm for this user that you stored in the database, and if it doesn't exist, generate a new one. Good one! The only bad thing I see is that the realm is visible in the dialog box the user see, isn't it? Seeing a random string might be a bit unsettling for the user, but there is no technical reason for it not to work. -- Pierre Phaneuf Systems Exorcist
Re: Authentication handlers
- Original Message - From: Pierre Phaneuf [EMAIL PROTECTED] To: modperl [EMAIL PROTECTED] Sent: Monday, March 05, 2001 9:29 AM Subject: Re: Authentication handlers Cees Hek wrote: So instead of storing a y/n in the database, store a unique string that is used as the realm, and clear it when they log out. Now everytime you send the Authenitication required header, send the unique realm for this user that you stored in the database, and if it doesn't exist, generate a new one. Good one! The only bad thing I see is that the realm is visible in the dialog box the user see, isn't it? Seeing a random string might be a bit unsettling for the user, but there is no technical reason for it not to work. -- Pierre Phaneuf Systems Exorcist Hi, Are you guys sure about this ? I just tried it out and it doesn't work for Apache1.3.12(win32) on win 98. I visited a page in a 'basic authentication' protected directory, then changed the name of the realm from 'htdocs access' to 'htdocs' but was still able to access other pages in the same directory without being hit for username and password. I tried hitting the back button and 'refreshing', and I also visited another site in the interim. All to no avail. Cheers, Rob Gilmour Visit our website at http://www.kalinabears.com.au
Re: Authentication handlers
On Sun, 4 Mar 2001, Pierre Phaneuf wrote: Good one! The only bad thing I see is that the realm is visible in the dialog box the user see, isn't it? Seeing a random string might be a bit unsettling for the user, but there is no technical reason for it not to work. Well, since the only requirement is that it is different from the last Realm you sent, (ie it doesn't need to be unique across all users), you could easily use the date and time. Something like Secure Area (Mar 5, 2001 10:51:02) This would have the side effect of also telling you when the user logged in. You would have to check the RFC to see what the size limit is on a Realm. -- Cees
Re: Authentication handlers
On Mon, Mar 05, 2001 at 10:28:15AM +1100, Sisyphus wrote: - Original Message - From: Pierre Phaneuf [EMAIL PROTECTED] To: modperl [EMAIL PROTECTED] Sent: Monday, March 05, 2001 9:29 AM Subject: Re: Authentication handlers Cees Hek wrote: So instead of storing a y/n in the database, store a unique string that is used as the realm, and clear it when they log out. Now everytime you send the Authenitication required header, send the unique realm for this user that you stored in the database, and if it doesn't exist, generate a new one. Good one! The only bad thing I see is that the realm is visible in the dialog box the user see, isn't it? Seeing a random string might be a bit unsettling for the user, but there is no technical reason for it not to work. -- Pierre Phaneuf Systems Exorcist Hi, Are you guys sure about this ? I just tried it out and it doesn't work for Apache1.3.12(win32) on win 98. I visited a page in a 'basic authentication' protected directory, then changed the name of the realm from 'htdocs access' to 'htdocs' but was still able to access other pages in the same directory without being hit for username and password. I tried hitting the back button and 'refreshing', and I also visited another site in the interim. All to no avail. Hi, there are two things to consider here. First, the server really has to send the AUTH_REQUIRED + realm; second, the browser does have to honor that authentication request by asking the user for a new name/password. Typically, servers are set up not to send the AUTH_REQUIRED response code, when the browser already is sending a valid username/password combination. And that's where browser caching comes into play: having queried the user once for username/password, the browser associates it with that specific URL and automatically resends it for each subsequent request to that location (which usually makes sense as it avoids another round trip to the server). Now, what happens if the server is configured such that it sends an AUTH_REQUIRED, even though it did already get the basic authorization header? Well, as so often, it depends on the browser. Netscape, for example, does pop up a dialog box, asking for re-authentication, while IE simply resends the same old username/password combination again. Thus, in IE you don't get a chance to enter any new credentials for a certain location which you've already visited in the current browser session. M$ obviously thought that this would never make sense ;( (it effectively means that you have to restart IE, if you need to login anew...) I haven't yet tested this issue again to see what happens when bringing the "changing realms"-idea into play. Maybe an AUTH_REQUIRED + _new_ realm would even convince IE to allow re-authentication... ;) Erdmut -- Erdmut Pfeifer science+computing gmbh -- Bugs come in through open windows. Keep Windows shut! --
Re: Authentication handlers
"Paul J. Lucas" wrote: Is there any means of removing the username and password from the browsers cache. $r-nocache(1); No, I think he's talking about the "basic" authentication information, that browsers keep in memory until they are stopped. I think that if you give them an AUTH_REQUIRED, it might clear the password, but that would also make the authentication dialog box appear on their machine, which would be rather confusing. Personally, I use cookies for authentication instead, you can remove those at will. -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: Authentication handlers
At 12:58 PM 03/03/01 +0530, Kiran Kumar.M wrote: hi , i'm using mod_perl authentication handler, where the user's credentials are checked against a database and in the database i have a flag which tells the login status (y|n), but aftr the user logs out the status is changed to n , my problem is that after logging out if the user goes one page back and submits the browser sends the username and password again , and the status is changed to y . Is there any means of removing the username and password from the browsers cache. I guess I don't understand you setup. If you have a database entry that says they are logged out why don't you see this when they send their request and return a "Sorry, logged out" page? I wouldn't count on doing anything on the client side. Bill Moseley mailto:[EMAIL PROTECTED]
Re: Authentication handlers
Bill Moseley wrote: i'm using mod_perl authentication handler, where the user's credentials are checked against a database and in the database i have a flag which tells the login status (y|n), but aftr the user logs out the status is changed to n , my problem is that after logging out if the user goes one page back and submits the browser sends the username and password again , and the status is changed to y . Is there any means of removing the username and password from the browsers cache. I guess I don't understand you setup. If you have a database entry that says they are logged out why don't you see this when they send their request and return a "Sorry, logged out" page? The problem here is that the first basic authentication is not any different from the next ones, so if he marks the user as logged out, going to an page requiring authentication will simply mark the user as logged in. You could try various tricks still, with accordingly varying degrees of success. While you might have a number of pages protected by basic authentication, make only *one* of them actually mark the user as logged in. For example, that might be /login. An example user session might look like this: - go to / - click on the "login" link, sending him to /login - /login is protected, so browser queries the user for authentication - /login sees the basic authentication header, marks the user as logged in - user do whatever he wants - user is logged out After this point, if the user goes to any protected web page, even though the basic authentication header is actually correct, he should get a AUTH_REQUIRED response, because he isn't marked as logged in by the database. The only page with the power to make the user logged in is /login. There is a security problem with this. The user/password combo is *not* cleared from the browser! If someone logs out, then a passer-by uses the same browser to log into the site, he will not get any question asked and will be identified as the previous user! Basic authentication is annoying. They forgot to put a way to revoke the thing when they designed it. Eh, that's life... -- Pierre Phaneuf http://www3.sympatico.ca/pphaneuf/
Re: Authentication handlers
On Sat, 3 Mar 2001, Pierre Phaneuf wrote: "Paul J. Lucas" wrote: Is there any means of removing the username and password from the browsers cache. $r-nocache(1); No, I think he's talking about the "basic" authentication information, that browsers keep in memory until they are stopped. Oh, silly me. Since this is a mod_perl mailing list, I thought it was actually mod_perl question. Basic authentication is basic authentication; mod_perl has nothing to do with it. - Paul
Re: Authentication handlers
At 10:11 AM 03/03/01 -0500, Pierre Phaneuf wrote: The problem here is that the first basic authentication is not any different from the next ones, so if he marks the user as logged out, going to an page requiring authentication will simply mark the user as logged in. That's what I was assuming. Basic authentication is annoying. They forgot to put a way to revoke the thing when they designed it. Eh, that's life... That's the real point. Sometimes you have to weigh the use of a always-on feature like basic authentication vs. maybe-on cookies. If you really must use basic authentication then besides the AUTH_REQUIRED trick, sometimes you can get clients to forget by sending them to a new URL with an embedded username and password that logs into the same AuthName but with a different username/password combination. But, you CAN'T count on anything working unless you know all your clients -- if even then. If your problem is that some clients don't use cookies, then perhaps Apache::AuthCookieURL might help. Bill Moseley mailto:[EMAIL PROTECTED]
Authentication handlers
hi , i'm using mod_perl authentication handler, where the user's credentials are checked against a database and in the database i have a flag which tells the login status (y|n), but aftr the user logs out the status is changed to n , my problem is that after logging out if the user goes one page back and submits the browser sends the username and password again , and the status is changed to y . Is there any means of removing the username and password from the browsers cache. Thanks in advance Kiran
Re: Authentication handlers
On Sat, 3 Mar 2001, Kiran Kumar.M wrote: Is there any means of removing the username and password from the browsers cache. $r-nocache(1); - Paul
