Re: Authentication design
There are at least 2 places where the idea can be improved to be even better: 1) for browsers that do not support cookie, embed the ticket/credential in the URL so the system works for all browsers 2) the part for ticket verification can be written in C so in case of dual-server setup (light plus proxy), which is kind of popular now, one can set it up in the light server to protect static content. Peter - Original Message - From: Michael L. Artz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 6:47 PM Subject: Re: Authentication design Well, sorta. I am actually using a custom module very similar to the one found in the cookbook (and AuthCookie, I think), i.e. create a PerlAuthenHandler that sets the custom error message to the login page and redirects you to it if you pass it an incorrect user/password request. If it the user/pass checks out, I set a session cookie (md5 sum of stuff), store the session_key in the database (Postgres), and set $r-user. If no user/password or cookie is presented, I just return OK for most of the site. A couple of scripts are login-only, and those are protected by an authz handler that makes sure $r-user is set. Everything is handled with my custom login forms, none of the crappy pop-ups for basic or digest authentication. So I guess that I am usurping the normal HTTP-authentication phase for my own nefarious purposes. I thought that this was a good way to go since I could protect my entire application with a single module and a couple lines in the config file, as opposed to bundling that authentication code into the beginning of *every* registry script that I write. And, from lurking on the board for a long time, I got the feeling that this is how everyone is doing it is that a correct assumption? -Mike
Re: AuthCookie questions
check here http://modperl.home.att.net Peter - Original Message - From: Christian Gilmore [EMAIL PROTECTED] To: 'Michael Schout' [EMAIL PROTECTED] Cc: 'Modperl Mailing List (E-mail)' [EMAIL PROTECTED] Sent: Tuesday, October 22, 2002 12:13 PM Subject: RE: AuthCookie questions Hi, Michael. Let me try again with more specifics. I'm required to mash my service into another organization's authentication scheme, ditching my own secure methods for their cross-domain unencrypted, unsigned cookie. 1. Foreign server, foreign.foo.com, presents a form to a user requesting userid/password. Foreign server accepts credentials and creates simple session cookie whose domain is foo.com containing a string of unencrypted key/value pairs. 2. User comes to my local server, local.foo.com, and sends along his cookie for domain foo.com. I need to parse out one of the key/value pairs and populate an environment variable (aside from REMOTE_USER) with the pair's data. If the user comes without the cookie or without appropriate data in the cookie, I need to redirect him to foreign. I am also asked to not create any other cookies. All the data I need is in the one cookie that comes from foreign. So, my needs boil down to: 1. Read data from existing cookie. 1a. Redirect if cookie is non-existent. 2. Accept or reject cookie. 2a. If rejected, redirect. 2b. If accepted, populate environment and return. On a side note, if anyone finds the proposed design lacking for security or anything else, please let me know. Thanks, Christian - Christian Gilmore Technology Leader GeT WW Global Applications Development IBM Software Group -Original Message- From: Michael Schout [mailto:mschout;gkg.net] Sent: Tuesday, October 22, 2002 2:00 PM To: Christian Gilmore Cc: Modperl Mailing List (E-mail) Subject: Re: AuthCookie questions Christian Gilmore wrote: 4. I cannot modify the cookie and should not send additional cookies. [snip] about 4. Can I use an unmodified AuthCookie to ensure that whatever format the inbound cookie is in is sufficient and will not need to be modified or supplemented? I believe the answer is no, and, if it is, should this be What exactly do you mean by this? What are you trying to accomplish? Do you mean The user cannot modify the cookie? If thats what you mean, then yes, there are ways to do that. Basically you have to cryptographically sign the cookie using a secret that is unknown to the end user. There is an example of this in the Eagle book, and Apache::AuthTicket uses a scheme similar to this. Because you cant control what the cookie server sends, you'd probably have to do some sort of double redirect For example: o user is redirected to auth server o auth server returns cookie and redirects to /SIGNHANDLER o signhandler gets the cookie, cryptographically signs it, and returns the cookie to the client and redirects to real location o user is redirected to real location. If thats not what you mean, please elaborate. Regards, Mike
Re: serving large files with access controls
We talked about this limiation of the dual setup before. There is no solution publically available. But you can try this: 1) check http://modperl.home.att.net or similar cookie-based ticketing system. 2) write a ticket-client module in C and load it into the proxy server (I have one based on libapreqs). 3) you can use the same ticket issuer mod_Perl module in the server machine, or any language as far as it can generate a valid cookie. 4) then serve the large file directly via the proxy server. Peter - Original Message - From: Erik Rantapaa [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 13, 2002 12:54 PM Subject: serving large files with access controls Suppose I have a typical proxied mod-perl setup and I have a large (~ 650 MB) file I'd like to provide authenticated access to. The mod-perl server will be doing the authentication, but for performance considerations I'd like the proxy server to serve the file directly instead of having the mod-perl server first forward the file to the proxy. Is there a way to do this so that access to the file would be _impossible_ unless the user is authenticated by the mod-perl server? I am looking for a solution that can guarantee that there is no way to circumvent the authentication process. I can think of solutions where the probability that users can access the file without authenticating can be made very small, but I am looking for an absolute guarantee. Regards, Erik Rantapaa [EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
Re: UTF8 character issue with Apache::Request?
Please take a serious look. There were several related reports in the mailing list during the months: Apache::Request might not handle double-bytes or utf8 correctly. Or it may be due to the C library. Peter - Original Message - From: Joe Schaefer [EMAIL PROTECTED] To: [EMAIL PROTECTED]; modperl list [EMAIL PROTECTED] Sent: Saturday, September 28, 2002 10:08 AM Subject: Re: UTF8 character issue with Apache::Request? [EMAIL PROTECTED] writes: [...] With Kanji filename : Size is 0 UPL:Content-Disposition=form-data; name=UPLOADFILE; filename=.DOC UPL:Content-Type=application/octet-stream Without Kanji filename Size is 306688 UPL:Content-Disposition=form-data; name=UPLOADFILE; filename=copy.DOC UPL:Content-Type=application/msword Any thoughts or input would be great. Are you certain this is a server-side problem? The varying Content-Types look suspicious to me. I'd double-check (via tcpdump or something) that the client is actually sending the whole file to the server. -- Joe Schaefer
Re: performance regarding mod_perl vs mod_c with embedded perl
The linked page is great, especially the first picture. Problem in authentication: if mod_perl returns cached header and the document is proxy cached in the plain Apache, the backend authentication handler (in the mod_perl server) will not be able to protect it. Peter Bi - Original Message - From: Ask Bjoern Hansen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Josh Chamas [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 3:36 AM Subject: Re: performance regarding mod_perl vs mod_c with embedded perl You don't do that for raw performance as measured in a typical simple benchmark environment. The dual setup is used to not needlessly waste resources in a real setup. Raw benchmark numbers will come out a bit lower, but you don't care as a proper setup will save you LOTS of memory, database connections and what have you not. http://develooper.com/modperl/performance_tuning.html (Click Next on the top of each slide to progress ... The first few slides looks weird in Mozilla 1.0 on my Linux box but are fine in Chimera on Mac OS X - get a Mac! :-) ) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: odd authetication situation
Maybe you can try to add specifically:
$r-connection-user('who_the_user_is') before the cookie access control
returns OK in the module. Note that some of the cookie authentication
modules are based on access-only control so $r-connection-user() can
return a value in late phases only if one assigns it at the first place.
Peter Bi
- Original Message -
From: Michael Robinton [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, August 28, 2002 1:05 PM
Subject: odd authetication situation
I have a modperl handler that sets a cookie and does a redirect if the
cookie was not present. The redirected page eventually loads the same page
again. In addition, this page is called from a protected portion of the
site that requires Basic Auth.
When the redirect calls the mod_perl routine the second or some
subsequent times, $r-connection-user and $ENV{REMOTE_USER} are both
empty or non-existent yet the page does not appear to fail the
authentication request and executes and returns html.
The failure is repeatable though not consistently so, maybe 70% or more.
I'm scratching my head on this one. Any ideas??
Michael
Re: large projects in mod_perl
How about application software ? The lists are either programming tools or language iteself. I mean something like ... online accounting software ... just for example. Peter Bi - Original Message - From: Per Einar Ellefsen [EMAIL PROTECTED] To: zt.zamosc.tpsa.pl [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 27, 2002 12:43 AM Subject: Re: large projects in mod_perl At 09:16 27.08.2002, zt.zamosc.tpsa.pl wrote: Hi all Does anyone know where I can find some information on creating big projects in Perl (mod_perl)? I am facing the really big project now but I don't know what stucture of the program will be the best. There are such things like Struts, jBoss in Java. What about Perl? Well, with mod_perl you have many possibilities. I would advise you to read http://perl.apache.org/docs/tutorials/apps/scale_etoys/etoys.html for an explanation about a big project involving mod_perl at EToys, and http://perl.apache.org/products/app-server.html for a list of application servers available for mod_perl (as well as maybe http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html to look at how to choose a templating system). You might also want to develop your own architecture based on MVC, which we had a long discussion about here recently. For a lot of interesting reading, look at these threads: o http://mathforum.org/epigone/modperl/jilgygland o http://mathforum.org/epigone/modperl/pahphucree o http://mathforum.org/epigone/modperl/solchaxzim o http://mathforum.org/epigone/modperl/lerdginspir o http://mathforum.org/epigone/modperl/stremnemcland o http://mathforum.org/epigone/modperl/nounumspim o http://mathforum.org/epigone/modperl/blildeudrand o http://mathforum.org/epigone/modperl/zhathontimp o http://mathforum.org/epigone/modperl/drehkrerlnen o http://mathforum.org/epigone/modperl/drurflerdplald -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: NTLM module
Adam: Netscape does behave somehow differently under the authentication. I used to have similar problem with a Perl authen module using Netscape 6 (Netscape 4.0 and 3.0 are okay, however). It looks like N6 uses more caching, and does not tolerate any departure from the httpd 1.1 definition; so one gets often the same pop-up login page instead of the redirected page. You may try to remove any caching tags and add nocache in the code. Peter - Original Message - From: Kaye-Smith Adam [EMAIL PROTECTED] To: Gerald Richter [EMAIL PROTECTED]; Peter Bi [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 19, 2002 9:46 PM Subject: RE: NTLM module I am still having problems with the AuthenNTLM module. All works fine for IE and Mozilla browsers but when I use Netscape, I am repeatedly promted for passwords. If I enter my password about 3 to 6 times I will eventually get the full page . If I enter password once, ( and cancel for any further password prompts ) I get only bit of the expected page. If I put a sleep (2) in the perl module before it goes to verify against the SMB server, netscape browser will work albeit somewhat slower. The other aspect I can not understand is that when the perl NTLM module is running, it will often exit from sub's other than the handler sub. ie the handler sub is always called first which calls other sub's but whilst executing these other sub''s , it appears that something seems to cut processing short passes control back to apache - the perl code never gets a chance to return to the handler module exit code with a 'return xx'. I have been observing the perl's progress by looking at entries in the error.log . I have also put in a variety of print STDERR staements at key positions to see where the code is exiting. If for instance I put a sleep command in the perl module, the code will often exit whilst the sleep is taking place - it appears that the NTLM module has run out of its allowed time and it has been cut short. The other conclusion is that multiple threads are running and outputting to the error.log confusing me with the overlapping output. This strange exiting behaviour also appears to occur on all browsers (once that work ok netscape that does not work.) The other error I get is that the username/password is passed ok from the SMB server verification phase, but then in subsequent calls to the SMB server, the username/password fails - this occurs during the one entry of username/password but the SMB server is contacted several times for verification ( I also check the username password in the script before thay are submitted to the SMB server so I know they are correct.) Would this be because of timeout in the SMB to respond. I would also expect the SMB server to only need to referred to once, but the perl module is calling the SMB module 3 times during the one username/password entry. I hope the above make sense. I can my log file if this would help. Regards Adam -Original Message- From: Kaye-Smith Adam Sent: Monday, 19 August 2002 9:15 AM To: 'Gerald Richter'; Peter Bi; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: NTLM module Thanks for your advice Gerald. I have found a compromise buy having the directive of Authtype Basic but the perl code has been changed to run the NTLM check as well as SMB (regardlesss of the config file) and if both authentications fail, the standard mod_auth code will then be run. Thanks once again. Adam The information in this e-mail together with any attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any form of review, disclosure, modification, distribution and/or publication of this e-mail message is prohibited. If you have received this message in error, you are asked to inform the sender as quickly as possible and delete this message and any copies of this message from your computer and/or your computer system network.
Re: NTLM module
Gerald: if you check the source of the Smb implemenation of the module, you would see that it performs basically the same function as NTLM. I agree with you that it does not fit the Microsoft definition of NTLM, so it is not a NTLM implementation. If ones purpose is to pass the protection by providing a valid username/password pair in a NT domain, then one does not have to follow that definition and the current Smb implementation is one of the possible solutions. Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:53 AM Subject: Re: NTLM module You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. I think you missed the point (or I missunderstood your module): The problem is not doing the authentication against whatever, but doing NTLM authetication. With NTLM auth you don't get a password from the client, so how would compare the password that you don't have against SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. ? The only solution is to reimplement the challage/response that NTLM does. (The module Authen::Perl::NTLM maybe helpfull here). To do this you need either the password in clear text to compute the nt password hash (a sort of md4 hash) or the precomputed nt password hash. You won't have this with LDAP, IMAP, NIS, FTP, LWP and DBI etc Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - Cheers. Peter Bi - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 9:12 PM Subject: Re: NTLM module According to the documentation, if you set NTMLauthoritative to off, then if NTLM authorization fails, then it should pass it on to the lower level modules. Yes, that's true and it works like you describe it. The point that you are missing is (and that I have tried to show in my last mail), that during NTLM authentication there is no password! NTLM never passes the password to the server, so also the control gets passed to the lower level module, this lower level module must be able to handle NTLM. The default Apache auth handler isn't able to do so. It expects a password, which it doesn't gets because the client never has send it. Hope it's a little bit more clear now Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - I have cut out the below section from the doco which relates to the above functionality : =head2 PerlSetVar ntlmauthoritative Setting the ntlmauthoritative directive explicitly to 'off' allows authentication to be passed on to lower level modules if AuthenNTLM cannot autheticate the userand the NTLM authentication scheme is used. If set to 'on', which is the default, AuthenNTLM will try to verify the user andif it fails will give an Authorization Required reply. =head2 PerlSetVar basicauthoritative Setting the ntlmauthoritative directive explicitly to 'off' allows authentication to be passed on to lower level modules if AuthenNTLM cannot autheticate the userand the Basic authentication scheme is used. If set to 'on', which is the default, AuthenNTLM will try to verify the user andif it fails will give an Authorization Required reply. From the above description, I am hoping for the following events to take place - ntlm authentication (if fail this level go to next authentication) - basic authentication (if fails this level go to other authentication systems) - read passwords in htpasswd file ( if this fails, then access not granted) To enable the following behaviour, I have included the following directives in httpd.conf. - ntlmauthoritative off - basicauthoritative off I have also taken out the basic authentication to see
Re: NTLM module
The username/password pair is sent only once to the issuer machine and the follow-up authentications are performed using a self-certified, time-limited, hash. In fact, it is based on access-control, having nothing to do with Basic Authentication. This is discussed in detail in the Eagle book. I am not sure if NTLM is even better but for most applications, it is pretty secure. Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:29 PM Subject: Re: NTLM module if you check the source of the Smb implemenation of the module, you would see that it performs basically the same function as NTLM. I agree with you that it does not fit the Microsoft definition of NTLM, so it is not a NTLM implementation. If ones purpose is to pass the protection by providing a valid username/password pair in a NT domain, then one does not have to follow that definition and the current Smb implementation is one of the possible solutions. The point is not how the password is passed to the nt server, the point is how the browser and the web server exchange the credenticals. With basic auth and with your module the user enters a username and a password and you use different backends to verify this. With NTLM authentication the Internet Exploerer and the Web server uses a challange-response procdure to exchange credenticals (and IE does this without asking the user, so you get logged on with your windows username, which safes the user some extra typing). They never send the password over the wire, so you don't have a password to send/verify to your backend. What you talking about is the verification of the password between the web server and the nt domain controller, thats something different. Gerald Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:53 AM Subject: Re: NTLM module You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. I think you missed the point (or I missunderstood your module): The problem is not doing the authentication against whatever, but doing NTLM authetication. With NTLM auth you don't get a password from the client, so how would compare the password that you don't have against SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. ? The only solution is to reimplement the challage/response that NTLM does. (The module Authen::Perl::NTLM maybe helpfull here). To do this you need either the password in clear text to compute the nt password hash (a sort of md4 hash) or the precomputed nt password hash. You won't have this with LDAP, IMAP, NIS, FTP, LWP and DBI etc Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - Cheers. Peter Bi - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 9:12 PM Subject: Re: NTLM module According to the documentation, if you set NTMLauthoritative to off, then if NTLM authorization fails, then it should pass it on to the lower level modules. Yes, that's true and it works like you describe it. The point that you are missing is (and that I have tried to show in my last mail), that during NTLM authentication there is no password! NTLM never passes the password to the server, so also the control gets passed to the lower level module, this lower level module must be able to handle NTLM. The default Apache auth handler isn't able to do so. It expects a password, which it doesn't gets because the client never has send it. Hope it's a little bit more clear now Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax
Re: NTLM module
Gerald: Any comment on Paulo's question ? (I am interested in that knowledge too.) I doubt that NTLM does not need any password. Logically, there must be a way to set up the initial trustful connection between two machines. If not password, what will that be ? Or something like Digital Authentication ? Peter - Original Message - From: [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 2:36 PM Subject: Re: NTLM module Am I totally wrong, or the plain and painful answer is that NTLM is only supported on Win32 boxes? I think I read somewhere that, because the module relies the Win32 API, it doesn't run on other systems. It even said something like ...whoever wants to grab some Samba code and port the module to *nix, please do Again, this is just something I guess I think I read somewhere, so take it with a grain of salt. Paulo Meireles MCSE (and not ashame of it) ;-) Como Reduzir os Riscos de Segurança da Sua Organização Whitepaper Gratuito sobre Serviços de Segurança http://www.vianetworks.pt/security/whitepaper_fs.html and - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 8:58 PM Subject: Re: NTLM module The username/password pair is sent only once to the issuer machine and the follow-up authentications are performed using a self-certified, time-limited, hash. In fact, it is based on access-control, having nothing to do with Basic Authentication. This is discussed in detail in the Eagle book. I am not sure if NTLM is even better but for most applications, it is pretty secure. NTLM is a bit more secure, but also this is not the point here. NTLM auth doesn't require you to enter your password at all. I don't argue that NTLM is better, it just fits better in some intranet situations, because the user doesn't have to type in the username/password. It's seems that I was not clear enough. The only thing I say is that under the precondition you want to use NTLM client authetication, you can't use the way your module verifies the password. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:29 PM Subject: Re: NTLM module if you check the source of the Smb implemenation of the module, you would see that it performs basically the same function as NTLM. I agree with you that it does not fit the Microsoft definition of NTLM, so it is not a NTLM implementation. If ones purpose is to pass the protection by providing a valid username/password pair in a NT domain, then one does not have to follow that definition and the current Smb implementation is one of the possible solutions. The point is not how the password is passed to the nt server, the point is how the browser and the web server exchange the credenticals. With basic auth and with your module the user enters a username and a password and you use different backends to verify this. With NTLM authentication the Internet Exploerer and the Web server uses a challange-response procdure to exchange credenticals (and IE does this without asking the user, so you get logged on with your windows username, which safes the user some extra typing). They never send the password over the wire, so you don't have a password to send/verify to your backend. What you talking about is the verification of the password between the web server and the nt domain controller, thats something different. Gerald Peter - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 13, 2002 12:53 AM Subject: Re: NTLM module You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. I think you missed the point (or I missunderstood your module): The problem is not doing the authentication against whatever, but doing NTLM
Re: NTLM module
You may check Apache::Access module at http://modperl.home.att.net in which I tried to provide a general solution to several popular authentication issuers such as SMB, LDAP, IMAP, NIS, FTP, LWP and DBI etc. Cheers. Peter Bi - Original Message - From: Gerald Richter [EMAIL PROTECTED] To: Kaye-Smith Adam [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 9:12 PM Subject: Re: NTLM module According to the documentation, if you set NTMLauthoritative to off, then if NTLM authorization fails, then it should pass it on to the lower level modules. Yes, that's true and it works like you describe it. The point that you are missing is (and that I have tried to show in my last mail), that during NTLM authentication there is no password! NTLM never passes the password to the server, so also the control gets passed to the lower level module, this lower level module must be able to handle NTLM. The default Apache auth handler isn't able to do so. It expects a password, which it doesn't gets because the client never has send it. Hope it's a little bit more clear now Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 - I have cut out the below section from the doco which relates to the above functionality : =head2 PerlSetVar ntlmauthoritative Setting the ntlmauthoritative directive explicitly to 'off' allows authentication to be passed on to lower level modules if AuthenNTLM cannot autheticate the userand the NTLM authentication scheme is used. If set to 'on', which is the default, AuthenNTLM will try to verify the user andif it fails will give an Authorization Required reply. =head2 PerlSetVar basicauthoritative Setting the ntlmauthoritative directive explicitly to 'off' allows authentication to be passed on to lower level modules if AuthenNTLM cannot autheticate the userand the Basic authentication scheme is used. If set to 'on', which is the default, AuthenNTLM will try to verify the user andif it fails will give an Authorization Required reply. From the above description, I am hoping for the following events to take place - ntlm authentication (if fail this level go to next authentication) - basic authentication (if fails this level go to other authentication systems) - read passwords in htpasswd file ( if this fails, then access not granted) To enable the following behaviour, I have included the following directives in httpd.conf. - ntlmauthoritative off - basicauthoritative off I have also taken out the basic authentication to see if this works ie Authtype ntlm (not basic) But this still does fail allow the htpasswd system to verify access. If there are changes that need to be made to the AuthenNTLM.pm, I am not very well read in this area - are there any goof references. From my novice perspective, it appears that when NTLM is included as part of the authentication, the ability for normal modules to verify access (ie htpasswd file) is no longer available ie the perl module does not pass back what the standard modules are expecting. I am sorry to be a bit unclear in my analysis, but I am fairly new to apache perl modules. Many Thanks Adam original email attached -Original Message- From: Gerald Richter [mailto:[EMAIL PROTECTED]] Sent: Monday, 12 August 2002 5:35 PM To: Kaye-Smith Adam; [EMAIL PROTECTED] Subject: Re: NTLM module - Original Message - From: Kaye-Smith Adam [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 12, 2002 4:51 AM Subject: NTLM module Hello , When I enter in an NT password it all works ok but when I use a user/pass from the htpasswd file, the only way it will work is that I change the above line to AuthType Basic instead of AuthType ntlm,Basic. With this change I can access passwords in htpasswd also authenticate from an NT server but I can no longer use NTLM. The problem is that Basic authentication requires a password from the client which can be compared against your password file. In case of NTLM auth, there is no password ever send over the wire, so Apache doesn't have anything which it can compare against it's passwd file. The solution would be to derive a class from AuthenNTLM and do the computation of the challage and response based on the secrets in the passwd file (you would need to store MD4 hashs of your passwords somewhere). There is a module called Perl::AuthenNTLM which may be helpfull in doing this task. Gerald
Re: Is it possible to change the browser's address/location URL without Redirect?
It is the browser that controls the URL in the Address bar. So one has to
make another call to get the URL refreshed. If you are worry about the
speed, you may
1) return an error code in case of error
2) in Apache's httpd.conf, config that specific error to display
/step/1/error
A simply redirection does the same job.
Peter
- Original Message -
From: Harry Zhu [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, August 09, 2002 11:26 AM
Subject: Is it possible to change the browser's address/location URL without
Redirect?
Looks like my explanation is too long or too bad.
The simple idea is in page step 1, after the
form action=/step/2 method=post.../form
submitted, I want the browser show something
http://www.example.com/step/1/error, instead of
http://www.example.com/step/2,
if there is a need for user to correct the data submitted.
It might be accomplished by using one of the approaches outlined below,
but
I was wondering if there's other way that can save the overhead of the
write/read or resend the data, and the re-process. Probably not much we
can
do if the URL displayed in the browser's address/location bar depends only
on the action value of the form submitted, not based on the server
response?
Harry
- Original Message -
From: Harry Zhu [EMAIL PROTECTED]
To: mod_perl list [EMAIL PROTECTED]
Sent: Thursday, August 08, 2002 4:22 PM
Subject: Can I change the browser's address/location?
Suppose I have a generic content handler to handle requst
/step/1, /step/2, ..., /step/n
Location /step
SetHandler perl-script
PerlHandler MyHandler
/Location
#MyHandler.pm
package MyHandler;
sub handler {
my $r=shift;
my $step = substr($r-path_info(),1);
#do something before fetch the content
#fetch content: usually include a form that will assign action
/step/($step+1)
}
So if everything goes well, the user will follow through from step 1,
step
2, until fnish.
Now if in the #do something ... part, something is wrong, it will
usually
require user go back to the same step, for example, to fill the form
again.
The way my old cgi script does is just generate the form with prefilled
value plus some error message indicate what's wrong. It works ok but the
browser location will show /step/($step+1) while it actually is
/step/$step.
Now that I am working it on mod-perl I thought I should be able to do
something about it. I briefly browsed the 2 mod-perl books (eagle,
cookbook), and could not found a simple solution yet (or I missed it?).
I
was think using one of the folowing might work:z
1) save the request data in a temp file and redirect or http-refresh to
/step/$step?$session_id or /step/$step/error?$session_id
Remember the content is dynamic and depend on the input form data, so
simple
redirect may not work.
Looks like Apache will not post the form data when redirect with
Location?
2) print a short form with hidden data and assign
action=/step/$step/error
then submit right away (onload=form.submit()?)
Does anybody have a simple solution, e.g. without redirect? Is it
possible
to change the URI showing in the browser's address/location bar?
I would appreciated if somebody can pointer me to the right direction.
Harry
Re: [OT] Better Linux server platform: Redhat or SuSe?
Maybe that depends on the project. We have a powerful BBS system, which contains: read/post messages, public and member sign ups, messages cached to disk or memory, email notification, fast sorting of message threads and follow-ups, and a number of other features. It consists of 5 modules and each module has only 100 - 300 lines. Well, we use HTML::Template that helps to separate the HTML codes from the modules. Having HTML in perl programs makes a big difference. Peter Bi - Original Message - From: Owen Scott Medd [EMAIL PROTECTED] To: Peter Haworth [EMAIL PROTECTED] Cc: Jean-Michel Hiver [EMAIL PROTECTED]; Gerd Knops [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, July 03, 2002 11:53 AM Subject: Re: [OT] Better Linux server platform: Redhat or SuSe? lol... We're running a little over 175000 lines of (mod)perl code, currently running on a mix of RedHat 7.1, 7.2, 7.3 and Advanced Server. Next? On Wed, 2002-07-03 at 09:41, Peter Haworth wrote: On Wed, 3 Jul 2002 11:40:44 +0100, Jean-Michel Hiver wrote: perl: Any iussues with perl/modperl? Besides modperl I will be running a perl application with a few hundred thousend lines of code... Wow. For reference last time I looked at slashcode it was about 25.000 lines I think. I wonder what kind of application would require more than that amount of Perl code :-) I'm sure someone else will post a bigger number, but my application (IOP Electronic Journals) has 55000 lines of code (including the odd blank line and comment, of course). And we're always adding new stuff, so it only ever gets bigger. -- Peter Haworth [EMAIL PROTECTED] We don't care how they do it in New York. Owen -- USMail: InterGuide Communications, 230 Lyn Anne Court, Ann Arbor, MI 48103 Phone:+1 734 997-0922 FAX: +1 734 661-0324 mailto:[EMAIL PROTECTED] http://www.interguide.com/~osm/
Re: Optional HTTP Authentication ?
Please check that the idea of this kind of authentication is to encrypt the ticket, instead of a plain session ID. If cookie is not available, having it on URI is a good idea. (Then one needs to have all links in a relative manner; see the Cookbook). Cookie itself does not make a secure session ID or a secure ticket. It is the encryption that does. Peter Bi - Original Message - From: Jean-Michel Hiver [EMAIL PROTECTED] To: Randal L. Schwartz [EMAIL PROTECTED] Cc: Jean-Michel Hiver [EMAIL PROTECTED]; Andrew Moore [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 30, 2002 10:07 AM Subject: Re: Optional HTTP Authentication ? What? The EU is going to make cookies *illegal*? I highly doubt this. Sorry, I am neither the lawyer nor the client, so I can't tell you... I know it's really stupid, but I am going to have to deal without cookies. Jean-Michel * For usability reasons encoding session IDs on URIs would be really Jean-Michel bad... users needs to be able to 'hack' the URIs without f***ing their Jean-Michel sessions! Why is a user hacking their URLs? I can answer that. http://www.useit.com/alertbox/990321.html cite * a domain name that is easy to remember and easy to spell * short URLs * easy-to-type URLs * URLs that visualize the site structure * URLs that are hackable to allow users to move to higher levels of the information architecture by hacking off the end of the URL * persistent URLs that don't change /cite i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, http://bigmegamarket.com/index.pl?id=231223412sid=56765454151 is not. Again it doesn't always make implementation easy :-/ Jean-Michel Therefore I have to use HTTP authentication... Even though the user/password is transmitted *in the clear* on *every single hit*, because you can't just use a session identifier? This is so very wrong from a security perspective. I have to agree with you on that. Cookies are probably far better than HTTP authentication. But I cannot use cookies. Period. I wish I could, because this was what I did in the first place and it was working fine! Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
Hi, Jean-Michel: the official way to retrieve the remote user name under
Basic Authentication is to call for $r-connect-user(), or $r-user() in
mod_perl 2.0, I think. With a ticket authentication, one gets the user name
in the same way only AFTER the access control phase, because it is simulated
from the ticket, see e.g. my Apache::CookieAccess source at
modperl.home.att.net. BTW, for me, Basic Authnetication is not that ugly, it
is surpringly stable (than most of other Apache ideas) since day one.
Peter Bi
- Original Message -
From: Jean-Michel Hiver [EMAIL PROTECTED]
To: Peter Bi [EMAIL PROTECTED]
Cc: Jean-Michel Hiver [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, June 30, 2002 12:20 PM
Subject: Re: Optional HTTP Authentication ?
On Sun 30-Jun-2002 at 10:47:26AM -0700, Peter Bi wrote:
Please check that the idea of this kind of authentication is to encrypt
the
ticket, instead of a plain session ID. If cookie is not available,
having
it on URI is a good idea. (Then one needs to have all links in a
relative
manner; see the Cookbook). Cookie itself does not make a secure session
ID
or a secure ticket. It is the encryption that does.
I *CANNOT* use cookies nor URIs for any kind of session tracking.
Otherwise I don't think I would have posted this message to the list in
the first place :-)
I agree that HTTP Basic authentication is totally and uterly ugly, but I
am going to have to stick with it no matter what... My problem is:
How do I tell apache to set the $ENV{REMOTE_USER} variable if the
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: when to mod_perl?
Thanks to the caching, any of my images or other static content gets pushed once a day to the front, and then doesn't tie up the back ever again. . I have a question regarding to the cached files. Although the maximal period is set to be 24 hours in httpd.conf's proxy settings, many of the files, which were cached from the backend mod_perl dynamical program, are strangely modified every a few minutes. For all the files I checked so far, they do look to be modified because the hex strings on top of the files (such as 3D189FC2) are different after each modifications. Forgive me if this is off-topic: it is more likely a mod_proxy question. I searched, but could not find related information pages to read. Thanks. Peter Bi - Original Message - From: Randal L. Schwartz [EMAIL PROTECTED] To: Perrin Harkins [EMAIL PROTECTED] Cc: md [EMAIL PROTECTED]; Stas Bekman [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, June 25, 2002 8:38 AM Subject: Re: when to mod_perl? Perrin == Perrin Harkins [EMAIL PROTECTED] writes: Perrin Static content is easy; just don't serve it from mod_perl. The proxy Perrin approach is good, and so is a separate image server (which you can Perrin host on the same machine). I've found thttpd to be an amazingly Perrin efficient server for images, but a slimmed-down apache does very well Perrin too. On the new www.stonehenge.com, I'm using a stripped down Apache (just mod_proxy and mod_rewrite) for a reverse caching proxy, and it's about 1.5M RSS per process. I divert requests for TT's /splash/images and Apache's /icons, but otherwise, all content requests (including for /merlyn/Pictures/ images) go to my heavyweight mod_perl backends, which are running about 10M RSS. Thanks to the caching, any of my images or other static content gets pushed once a day to the front, and then doesn't tie up the back ever again. On a 500Mhz 256M box, I'm easily serving 50K requests a day (about 10K of those are fully uncached dynamic pages touching about 20 to 50 TT includes), with loadaverages staying below 0.5. If it ever starts getting higher, I can cache the expensive menubar creation (which is nearly completely static) using Perrin's device, but I've not bothered yet. It's been amazingly carefree. I'm planning to move www.geekcruises.com to be served on the same box, although they get only about 1/10th the traffic. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: when to mod_perl?
- Original Message -
From: Randal L. Schwartz [EMAIL PROTECTED]
To: Peter Bi [EMAIL PROTECTED]
Cc: Perrin Harkins [EMAIL PROTECTED]; md [EMAIL PROTECTED];
Stas Bekman [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, June 25, 2002 10:18 AM
Subject: Re: when to mod_perl?
Peter == Peter Bi [EMAIL PROTECTED] writes:
Peter I have a question regarding to the cached files. Although the
Peter maximal period is set to be 24 hours in httpd.conf's proxy
Peter settings, many of the files, which were cached from the backend
Peter mod_perl dynamical program, are strangely modified every a few
Peter minutes. For all the files I checked so far, they do look to be
Peter modified because the hex strings on top of the files (such as
Peter 3D189FC2) are different after each modifications.
If you're talking about www.stonehenge.com, I don't provide
last-modified for any of the HTML pages: they're all dynamic. If the
proxy server is caching them, it's going to still punch through to the
back for each hit.
That is one of our sites.
Similarly, if you are talking about your own site, and you *do*
provide a mostly useless last modified time, then the front end is
still going to go to the back end and say I've got a version from
time $x, is that current? and if you're not handling
if-modified-since, then every hit will be cached, uselessly.
I used:
$r-update_mtime($id); # id is less than the current time and does not
change for a specific page
$r-set_last_modified;
if ($r-protocol =~ /(\d\.\d)/ $1 = 1.1){
$r-header_out('Cache-Control' = max-age= . 100*24*3600);
} else {
$r-header_out('Expires' = HTTP::Date::time2str($id + 100*24*3600));
}
It would not be surprising if none of the dynamic pages created was cached,
which then meant I had improper headers in mod_perl. In fact, they do serve
a number of views (maybe several tens) before modifying in the proxy
directory again. For example, I checked a file status:
$last access time: Tue Jun 25 11:44:12 2002
$last modify time: Tue Jun 25 11:40:52 2002
and for the same file later:
$last access time: Tue Jun 25 11:51:14 2002
$last modify time: Tue Jun 25 11:44:54 2002
so they were modified but not for every hits.
I avoid that on stonehenge by not providing last-modified for any of
my HTML pages. mod_proxy thus has no idea about caching, so it's all
dynamic. My images automatically have last-modified, and thus the
cache can check for updates with if-modified-since, using the cache
when needed. If I was really smart, I'd use mod_expires to say this
image is good for $N hours, and then the front end wouldn't even
touch the back end at all.
But if one makes a proper header, the proxy would not distinquish whether it
is static or dynamic. It should deliver or cache all the backend pages the
same way, providing the headers are right.
Here is another strange clue for me. The cached files have three extra
request headers X-Forwarded-For:, X-Host: , X-Server-Hostname: (from
mod_proxy_forward). While the files are modified continuously, the
X-Forwarded-For header, which record a browser's IP, does NOT change
although the later hits come from completely different IPs.
As I said, as long as my loadav is low enough for my current hits, I've
got better things to work on. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
training!
Peter Bi
Re: Preserving POST data on external redirect?
The link asks to change POST to GET. However, there is a limit on the length
of the URL so the POST data may be truncated and the redirect action may not
work properly.
Also, make sure to escapeURL() in the URL (which will also add extra chars
in the URL).
Peter Bi
- Original Message -
From: Kirk Bowe [EMAIL PROTECTED]
To: Ken Y. Clark [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, June 24, 2002 8:50 AM
Subject: Re: Preserving POST data on external redirect?
Hi, yes that's one of the pages that I've been looking at, and the code is
almost identical (I've tried M_GET / GET as well). Still nothing
happening for me :-)
Cheers
Kirk.
On Mon, 24 Jun 2002, Ken Y. Clark wrote:
On Mon, 24 Jun 2002, Kirk Bowe wrote:
Date: Mon, 24 Jun 2002 16:22:42 +0100 (BST)
From: Kirk Bowe [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Preserving POST data on external redirect?
Hi all, my content handler does some work with POSTed data, and at the
end
wants to redirect to a totally unrelated server, preserving the POST
data
that the client originally sent, so that the unrelated server can do
its
own further processing with its own mod_perl, cgi, or whatever.
I can't get it to work, as I think I'm getting confused by some
pre-Apache::Request hints that I've seen for this. This is the mess
I've
got so far (condensed):
sub handler
{
my $r = Apache::Request-new(shift);
... some calls to other subs here to do work ...
$r-method(POST);
$r-method_number(M_POST);
$r-headers_in-unset(Content-length);
$r-args($content);
$r-header_out('Location' = http://j.random.server.com/foo.cgi;);
$r-status(REDIRECT);
$r-send_http_header;
return REDIRECT;
}
It redirects, but doesn't pass the POST data. I thought it may have
been
due to the original post data being deleted because I use it, so I
tried
using Request-instance instead of Request-new, but that made no
difference either. Is it actually possible to do it if I'm using the
Request object?
Cheers
I think this is what you want:
http://theoryx5.uwinnipeg.ca/cgi-bin/guide-filter?page=snippets/Redirect_a_P
OST_Request_Forward.html;query=GET%20POST;match=and;where=all;stem=no
ky
Re: when to mod_perl?
wait a second ... don't forget using proxy: it saves you a lot of dynamical calls, especially if you have also a database. Peter Bi - Original Message - From: md [EMAIL PROTECTED] To: Stas Bekman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 24, 2002 9:36 PM Subject: Re: when to mod_perl? --- Stas Bekman [EMAIL PROTECTED] wrote: In any case we are talking about registry scripts, aren't we? In that case it takes very little time to turn it on and off and test what is better. Unless you are talking about writing full fledged mod_perl API handlers, which is only when your should plan/analyze before you code. Actually at first I was planning to do full fledged mod_perl handlers, so that's why I wanted to plan before I coded. I was just a bit worried about the amount of static content. In the past I've had a lot more hardware to work with and I never had to worry about it much. I think you all have answered my question well enough that I feel confortable sticking with straight mod_perl. Thanks... __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: [OT] what drives Amazon?
Hi, any comments on Java Servlet, .NET, mod_Perl and others such as ColdFusion ? I personally was asked for such question a few days ago. The other side needs a service like UPS.com. What do people on this mailing list think about ? Peter Bi - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: F. Xavier Noria [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, June 15, 2002 4:36 PM Subject: Re: [OT] what drives Amazon? Does anybody know which is the technology behind Amazon? If you look at their job listings, you'll see it's a lot of C/C++ and Perl, with a smattering of other things, running on Unix. That's pretty typical of the really big sites. - Perrin
Re: mod_perl/passing session information (MVC related, maybe...)
To Ward's first post: I think one may even doesn't need server cookie. Using a client-site cookie fits exactly the need. Peter - Original Message - From: Rob Nagler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 7:49 PM Subject: Re: mod_perl/passing session information (MVC related, maybe...) Perrin Harkins writes: My preferred design for this is to set one cookie that lasts forever and serves as a browser ID. I like this. It's clean and simple. In this sense, a browser is not really a session. The only thing I don't like is garbage collection. unique browser ID (or session ID, if you prefer to give out a new one each time someone comes to the site) lets you track this for unregistered users. We call this a visitor id. In the PetShop we have a cart id, but we're not too happy with the abstraction. I don't see that as a big deal. You'd have to delete lots of other data associated with a user too. Actually deleting a user is something I've never seen happen anywhere. We do. Especially when we went from free to fee. :-( The big issue I have with session data is that it is often a BLOB which you can't query. Well, eToys handled more than 2.5 million pages per hour, but caching can be important for much smaller sites in some situations. I'd like numbers on smaller and some. :) Here's a situation where a small site could need caching: We cache, too. An interesting query is the club count on bivio.com's home page. The count of clubs is a fast query, but the count of the members is not (about 4 seconds). We compute a ratio when the server starts of the members to clubs. We then run the club count query and use the ratio to compute the member count. We restart the servers nightly, so the ratio is computed once a day. Maybe I just have bad luck, but I always seem to end up at companies where they give me requirements like these. It's the real world. Denormalization is necessary, but only after you test the normal case. One of the reasons I got involved in this discussion is that I saw a lot of messages about solutions and very few with numbers identifying the problem. Rob
Re: Building high load mod_perl/Mason servers
General ideas are in Stas' introduction and other mod_perl books. Here are some practical numbers which may be useful for your reference. (assuming that all your servers have 1G RAM) 1) when daily unique IP are about 25K. Run mod_perl on the database machine with persistent Apache::DBI database connection. Turn one of the two frontend servers to be a light Apache server that a) serves all static contents and b) proxy to the mod_perl server for dynamical content. Leave the other frontend server to serve temporary PHP programs. With 1G in the frontend server, you are okay to run 500 MaxClients. 2) daily unique IPs are about 50k. Run both the frontend servers to be light Apaches and proxy to the mod_perl for dynamic contents. Memory may just be used up in the DB/mod_perl machine. If it is going to be a problem, try to remove Apache::DBI and use database cache to save memory but still keep a fast DB connection. Also, design the programs carefully to use caching ability in the light servers and/or to return proper headers (e.g. NOT_MODIFIED) as soon as possible. 3) daily unique IPs are about 100k. May need 3-4 frontend light Apaches, 1-2 mod_perl servers and 1 DB. Only with a daily unique IPs above 100k, one will defeintely needs two or more mod_perl servers. Synchronizing mod_perl codes should not be a problem --- for examply, simply mounted as NFS. Mod_perl calls the codes only once when starts. 4) Mason and other tools --- one can take the advantage for general development purposes. If the site has only a few specific services, it is better to write mod_perl from scratch than with a tool. These numebrs changed from sites to sites, I believe. The above numbers are based on our experience only. A popular web site usually contains many clients of slow network connections. So proxy is the key to serve them efficiently. Peter Bi - Original Message - From: Eric Frazier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 06, 2002 7:43 PM Subject: Building high load mod_perl/Mason servers Hi, I just got the chance to be in charge of a very busy website, and its future growth. Currently it is running with PHP on two round robin servers with a separate mysql db server. We are going to be moving to mod_perl, but I am worried about how to keep from getting into the same kind of trap with mod_perl as with PHP. The PHP guys don't know OOP, so we have to code halfway, modules exporter but not OOP modules. It has to be something OOP like without getting too complex at first. The PHP trap is just the horrible require once stuff all over the place and global vars etc. I know lots of people blame this kind of coding on perl geeks, but the PHP stuff I have been seeing is pretty bad with it because the constant thought is must fix current problem wait till later to be pretty but later never comes. Also things like using ten instr functions instead of one reg exp. So I am thinking whatever I do it should fit within an existing framework, something like Mason. But I am confused about what real advatage Mason provides, and how things like source code control would work if we are running lots of servers. Do people use rsync to keep up to date? Say one machine is always the upload point and the rest get synced from that one? I am having a hard time asking really good questions I think because there are so many things I am trying to think out. Thanks for any ideas, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Setting require in Authentication handler?
A remark: in many cases, the authentication against the password file can be replaced by verifying valid FTP/Telnet login to localhost, not only because the password (shadow) file is usually not avialble for Apache account but also secure. In the ticketing system, the FTP/Telnet authentication runs only at the first time of login and the follow-up access can goes without re-FTP and so is pretty fast. Check this : http://modperl.home.att.net Peter Bi - Original Message - From: Geoffrey Young [EMAIL PROTECTED] To: Todd Chapman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, May 20, 2002 6:50 AM Subject: Re: Setting require in Authentication handler? Todd Chapman wrote: That makes sense. I can't use mod_auth because I can't set Require. well, if you're saying that you don't have the ability to set the Require directive at all (as in you don't have access to edit httpd.conf), then you can't run any authentication handler - mod_auth, mod_perl, or otherwise. Apache core requires the Require directive to be set to something before it will even try to run the authen/authz phases of the request. so, you may be out of luck and need to resort to the CGI tricks of yore where everything is clumped in the content-generation phase (and of which I'm not that familiar). I'm using Basic authentication and text based password files. Unfortunately, I can't find an Apache::Auth* module that handles basic authentication against text files. Did I miss it somewhere? I'm not sure, but it may not exist for the reason I stated eariler about mod_perl not duplicating default Apache behavior. IIRC, there is one that authenticates against /etc/passwd, so maybe you can use that as an example of flat file based processing. in general, though, the steps are pretty much the same no matter which authentication method you choose. see http://www.modperlcookbook.org/code/ch13/Cookbook/Authenticate.pm for an example - all you need to do is replace the authenticate_user() subroutine with calls that validate the user based on your own criteria. HTH --Geoff
Re: Scripts and passwd
I dont even know if you can do it any other way with out touching the passwd/shadow files? Do you run this for internet or your intranet accounts ? If for internet, try something different (e.g. Courier/IMAP.) If for intranet, and if you have to stay with Pop3, there is no way but to touch the password file. If you don't mind a web-based mail, a possible solution may like this: 1) set up a normal web-based membership service; 2) write a mail filter; 3) catch every email and check if the recipient is in your database, (yes) ? move the mail to the DB : normal mailbox. Well, I think someone's in this maillist may have already such a system and can share their experience. On the other hand, while this has a lot to do with Perl, it has little with mod_Perl. Peter - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, May 19, 2002 1:56 AM Subject: Re: Scripts and passwd Hello Thanks for the reply. Yes this server is running mod perl :) As for risky. Well the whole point of the script system is to add a pop mail box for a user. But in order to do this i have to do the following: add user to the passwd/shadow file add user to the virtusertable and genericstable recompile the sendmail config files Then and only then is the new mailbox ready for use. This is the only way I can think of to accomplish this via an automated web proccess. I dont even know if you can do it any other way with out touching the passwd/shadow files? Thanks! John. You're doing something pretty risky there. the passwd/shadow files are only writable by root. So I suppose that when running them from the command line you run them as root. Apache doesn't run as root (its children which serve the requests atleast), so mod_perl (I suppose you *are* using mod_perl? If not, this is more appropriate for another newsgroup) won't either. If you can run your script as CGI, you could use suEXEC. But really, really consider the security implications of what you're doing there before allowing users to trash your machine very fast... -- Per Einar Ellefsen [EMAIL PROTECTED]
[JOB SEEK] Toronto - Re: [JOB] Mod_Perl/Sys Admin/HTML Tech Support - Los Angeles, CA
Hi, I shall fit 99% to Frank's job :-), but I have to move to Toronto soon. Looking for a mod_Perl or Perl related job in GTA (Toronto and Southern Ontario, Canada). Off-site contractor job is okay too. ASAP. Please check my resume at http://modperl.home.att.net . Thanks. Peter Bi p.s. I resist shifting to J2EE! - Original Message - From: Frank Scannello [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 13, 2002 4:56 PM Subject: [JOB] Mod_Perl/Sys Admin/HTML Tech Support - Los Angeles, CA The Partner Technical Team Support Engineer is dedicated to helping Partners maintain and administrate the Citysearch software. Because Partner needs, technologies, business requirements and languages vary widely, the candidate must be able to communicate effectively. Location: must be able to commute to 3701 Wilshire blvd in Los Angeles, CA. Relocation assistance not provided. Qualifications * Experience working in a webmaster-like role. A true web technologies generalist (part system administration (linux/unix), part front-end development (strong HTML), part back-end development (perl cgi, mod_perl ideal). * Significant Experience with perl scripting * Required - extensive knowledge of HTML. * Unix environment (basic administration) - 2 years I am assisting my client in finding and selecting qualified candidates for this position. The client is Ticketmaster City Search. Please respond with resume to: Frank Scannello Contract Recruiter [EMAIL PROTECTED] 904-543-0808
Re: Cheap and unique
Does the first email mean to use the incrementing numbers as seeds and then generate cool random numbers from the partly ordered seeds, which will make them more difficult to guess ? Peter Bi - Original Message - From: James G Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, May 06, 2002 11:45 AM Subject: Re: Cheap and unique [EMAIL PROTECTED] wrote: I've been following this conversation and I'd like to clarify whether my idea (since I and others want to do this as well) would be use an incrementing counter for uniqueness. Then also store a bit of secret randomness, concatenate both values together and create a digest hash. That hash would be sent along with the sequence as well. This would allow uniqueness and prevent guessing since the digest would have to match as well. Depending on my paranoia I could either get fresh random bits each time (and have a good hardware source for this then) or keep it around for a bit and throw it away after a period. I think I understand you correctly, but I'm not sure. You mention the sequence being incremented for uniqueness and the digest. I think you propose to send the sequence along with the digest (the digest containing that bit of randomness along with the sequence), but you also mention keeping the random bits around for only a short time, which would indicate they aren't being used to verify the sequence, but produce the sequence via the hash. A digest is not unique, especially with the random bit of data thrown in. For example, MD5 has 128 bits, but can hash any length string. There are more than 2^128 strings that MD5 can take to 128 bits. Therefore, MD5 does not produce a unique value, though it is a reproducable value (the same input string will always produce the same output string). You can replace MD5 with MHX (my hash X) and the number of bits with some other length and the results are still the same -- in other words, no hash will give unique results. The secret string concatenated with the unique number and then hashed can be used to guarantee that the number has not been tampered with, but the secret string would need to be constant to be able to catch tampering. Otherwise, how can you tell if the hash is correct? -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
Try my Apache::AccessCookie too. It provides the same ticketing interface for many different authenticating methods such as LDAP, IMAP, ftp, SMB, and (of course) DBI, plus a number of useful features. One can simply implement her own mechanism too. It can be downloaded at http://mod_perl.home.att.net. BTW, I tried to register the module in CPAN, but was kind of lost in the middle. Peter Bi - Original Message - From: Jim Helm [EMAIL PROTECTED] To: 'Fran Fabrizio' [EMAIL PROTECTED]; 'F.Xavier Noria' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 03, 2002 10:08 PM Subject: RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood) p.s. FWIW, I ended up using Apache::AuthTicket instead - has a feature I wanted (timeout, not just expiry), which CookieDBI didn't have), and it worked as documented with zero hassle... Jim -Original Message- From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:38 AM To: F.Xavier Noria Cc: [EMAIL PROTECTED] Subject: Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood) Does the server load the module that way? It's beyond my expertise at this point but my experience would indicate that it does not work this way since I have PerlModule before the PerlSetVar and it works fine. -Fran
Re: full-featured online database apps
Since the excellent HTML::Template, the codes becomes more re-usable... Peter - Original Message - From: Ken Y. Clark [EMAIL PROTECTED] To: Adi Fairbank [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 1:23 PM Subject: Re: full-featured online database apps I've written so many on-line database apps in mod_perl/MySQL/Oracle that I think I'll go crazy sometimes. They all have so much in common, esp. the typical administrative interface where you have to show all, show one, edit, create, [confirm] delete, etc. Everytime I find myself following the same basic formula, but they're all so significantly different that I can't really see reusing much code. I guess you could abstract things to such a degree that lots of directives could be passed to extremely generic methods, but that actually has always seemed more trouble to me than it's worth.
Re: full-featured online database apps
Well, I changed it back to HTML::Template . It takes relatively less time to work it out with graphic designers. Peter - Original Message - From: Wim Kerkhoff [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Ken Y. Clark [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 1:50 PM Subject: Re: full-featured online database apps Since the excellent HTML::Template, the code becomes more re-usable... Sorry, had to be said. My point is that there are many templating systems to choose from. With a bit of fore thought, the Show, List, Delete, Add, etc buttons can be moved into different objects/methods/templates, so that it's easier to pick and choose your interface components. Wim On 24-Apr-2002 Peter Bi wrote: Since the excellent HTML::Template, the codes becomes more re-usable... Peter - Original Message - From: Ken Y. Clark [EMAIL PROTECTED] To: Adi Fairbank [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 1:23 PM Subject: Re: full-featured online database apps I've written so many on-line database apps in mod_perl/MySQL/Oracle that I think I'll go crazy sometimes. They all have so much in common, esp. the typical administrative interface where you have to show all, show one, edit, create, [confirm] delete, etc. Everytime I find myself following the same basic formula, but they're all so significantly different that I can't really see reusing much code. I guess you could abstract things to such a degree that lots of directives could be passed to extremely generic methods, but that actually has always seemed more trouble to me than it's worth.
Re: full-featured online database apps
(agreed. let's stop talking on specific templates.) As to the reusability, form actions can actually be put in an abstract class, so a particular application can subclass it by implement of action methods with an optional xml control. But I have the same feeling as in Ken Clark's original post, one could not go too far beyond that, or not worth of doing that. Using an existing tool may solve one problem but it usually takes as much time to add or modify something later. On the other hand, the typical size of web projects nowadays is still well within our ability of write-from-scratch. Peter - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED] Cc: Wim Kerkhoff [EMAIL PROTECTED]; [EMAIL PROTECTED]; Ken Y. Clark [EMAIL PROTECTED] Sent: Wednesday, April 24, 2002 2:08 PM Subject: Re: full-featured online database apps Peter Bi wrote: Well, I changed it back to HTML::Template. No template flame wars, please. HTML::Template is not unique (it has much in common with Template Toolkit and dozens of other less famous modules from CPAN), and Embperl::Object is really pretty cool. Your original point about separating presentation out into templates helping with code reusability is a good one, so let's just leave it at that. - Perrin
Re: Throttling, once again
If merely the last access time and number of requests within a given time interval are needed, I think the fastest way is to record them in a cookie, and check them via an access control. Unfortunately, access control is called before content handler, so the idea can't be used for CPU or bandwidth throttles. In the later cases, one has to call DB/file/memory for history. Peter Bi - Original Message - From: kyle dawkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 19, 2002 8:02 AM Subject: Re: Throttling, once again Guys We also have a problem with evil clients. It's not always spiders... in fact more often than not it's some smart-ass with a customised perl script designed to screen-scrape all our data (usually to get email addresses for spam purposes). Our solution, which works pretty well, is to have a LogHandler that checks the IP address of an incoming request and stores some information in the DB about that client; when it was last seen, how many requests it's made in the past n seconds, etc. It means a DB hit on every request but it's pretty light, all things considered. We then have an external process that wakes up every minute or so and checks the DB for badly-behaved clients. If it finds such clients, we get email and the IP is written into a file that is read by mod_rewrite, which sends bad clients to, well, wherever... http://www.microsoft.com is a good one :-) It works great. Of course, mod_throttle sounds pretty cool and maybe I'll test it out on our servers. There are definitely more ways to do this... Which reminds me, you HAVE to make sure that your apache children are size-limited and you have a MaxClients setting where MaxClients * SizeLimit Free Memory. If you don't, and you get slammed by one of these wankers, your server will swap and then you'll lose all the benefits of shared memory that apache and mod_perl offer us. Check the thread out that was all over the list about a month ago for more information. Basically, avoid swapping at ALL costs. Kyle Dawkins Central Park Software On Friday 19 April 2002 08:55, Marc Slagle wrote: We never tried mod_throttle, it might be the best solution. Also, one thing to keep in mind is that some search engines will come from multiple IP addresses/user-agents at once, making them more difficult to stop.
Re: Throttling, once again
How about adding a MD5 watermark for the cookie ? Well, it is becoming complicated Peter Bi - Original Message - From: kyle dawkins [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, April 19, 2002 8:29 AM Subject: Re: Throttling, once again Peter Storing the last access time, etc in a cookie won't work for a perl script that's abusing your site, or pretty much any spider, or even for anyone browsing without cookies, for that matter. The hit on the DB is so short and sweet and happens after the response has been sent to the user so they don't notice any delay and the apache child takes all of five hundredths of a second more to clean up. Kyle Dawkins Central Park Software On Friday 19 April 2002 11:18, Peter Bi wrote: If merely the last access time and number of requests within a given time interval are needed, I think the fastest way is to record them in a cookie, and check them via an access control. Unfortunately, access control is called before content handler, so the idea can't be used for CPU or bandwidth throttles. In the later cases, one has to call DB/file/memory for history. Peter Bi - Original Message - From: kyle dawkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 19, 2002 8:02 AM Subject: Re: Throttling, once again Guys We also have a problem with evil clients. It's not always spiders... in fact more often than not it's some smart-ass with a customised perl script designed to screen-scrape all our data (usually to get email addresses for spam purposes). Our solution, which works pretty well, is to have a LogHandler that checks the IP address of an incoming request and stores some information in the DB about that client; when it was last seen, how many requests it's made in the past n seconds, etc. It means a DB hit on every request but it's pretty light, all things considered. We then have an external process that wakes up every minute or so and checks the DB for badly-behaved clients. If it finds such clients, we get email and the IP is written into a file that is read by mod_rewrite, which sends bad clients to, well, wherever... http://www.microsoft.com is a good one :-) It works great. Of course, mod_throttle sounds pretty cool and maybe I'll test it out on our servers. There are definitely more ways to do this... Which reminds me, you HAVE to make sure that your apache children are size-limited and you have a MaxClients setting where MaxClients * SizeLimit Free Memory. If you don't, and you get slammed by one of these wankers, your server will swap and then you'll lose all the benefits of shared memory that apache and mod_perl offer us. Check the thread out that was all over the list about a month ago for more information. Basically, avoid swapping at ALL costs. Kyle Dawkins Central Park Software On Friday 19 April 2002 08:55, Marc Slagle wrote: We never tried mod_throttle, it might be the best solution. Also, one thing to keep in mind is that some search engines will come from multiple IP addresses/user-agents at once, making them more difficult to stop.
Re: Sharing Variable Across Apache Children
What will happen if the client's DNS caches the domain name to an IP, which is then dead ? If I understand it corrently, the current system can work only if there is something like NAT in front of the machines, which dynaimcally forward each request. Won't it ? Peter Bi - Original Message - From: Medi Montaseri [EMAIL PROTECTED] To: Andrew Ho [EMAIL PROTECTED] Cc: Benjamin Elbirt [EMAIL PROTECTED]; modperl list [EMAIL PROTECTED] Sent: Wednesday, April 17, 2002 9:08 PM Subject: Re: Sharing Variable Across Apache Children You had us going for a whileI thought you are talking about some distributed session management (accross different boxes) Another suggestion is to use lbnamed. lbnamed is a DNS server and Load Balancing server that listens to port 53 and resolves IPs, but on the other side of its personality it talks to bunch of agents who are running on workers. You get to set what the parameters or criteria is and assign a cost factor for a worker. lbnamed then distributes the work on the lightest/least cost worker. In this scenario, whence a box is out (or its critical piece like Oracle, or HTTP server) then no further work is routed to it . Also, be aware that using CNAME in DNS does not provide a uniform distribution of load. Imagine a web page having 20 images and another 5 images. You'll not know with good certainty that if your heavy work like database access is really being distributed. With CNAME you do have a chance of developing harmonics. CNAME (aka round robin) is totally unaware of the load on the worker. Maybe that's why your boxes are bulking See http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html Andrew Ho wrote: Hello, BELet me explain in more detail what I'm doing. So if the situation you explain is the only reason you want a variable shared load balanced machines, I'd suggest a totally different way of doing this altogether. Best would be to use an already shared persistent storage mechanism (NFS or Oracle) but it looks like Oracle warnings are precisely what you want distinct alerts on (why are you getting so many Oracle errors anyway? that might be the first thing you want to check). I'm assuming the number of warning e-mails you get is less than 450,000 / 5 == 90,000 each day, so that if each warning e-mail were a web request, a single box could handle them (if more than 1/5 of your requests result in errors, you REALLY want to just fix the problem first). So put up a single webserver box to serve as an error reporter and logger. You could either use distributed logging (like mod_log_spread) or simpler, just set up another webserver that takes requests like /record_error.pl?error_msg=fooremote_addr=bar or whatever. Your error handlers on your five load-balanced boxes send an HTTP request to this error handling box. All error e-mails can originate from this box, and the box can internally keep a lookup table (using any of the fine techniques discussed by the folks here) to avoid sending duplicate errors. In this scenario error handling is offloaded to another box, and as a bonus you can track the aggregate number of errors each day in an automated way and run reports and such (without having to count e-mails in your inbox). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering -
Re: PREANNOUNCE: modperl banners project
Is mod_perl supposed to be the final choice of the name ? Someones suggested before to use a different name like Tomcat for Java. What is the latest conclusion ? Peter Bi - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 11:54 PM Subject: PREANNOUNCE: modperl banners project This is just a pre-announce... The short story: We need somebody to do the coordination for the modperl banners project, similar to what Jonathan has done with the new logo creation/selection project. The long story: We need to create a few banners, so we can use these as ads on friendly sites. I've already one tech site that wants to advertise us for free. I know that ads don't really work, but the targetted advertising is in a better shape. I think the current market standard is 468x60 and 150x40 (pixels) and size about 10k. It's been a long time since I was doing these myself, so I'm not sure what's the acceptable image format. Definitely not PNG (Since some older browsers crash on PNGs). but these can be converted to other more back-compat formats. Anyway, the coordinator should figure out all these details before posting the announcement, so to prevent confusing and time wasting. The coordinator will accept submissions from individuals and put them somewhere online (better pre-announce the url, so people can see the work in progress). I don't know yet if we will need to do the voting, but it's an option. All depends on how many banners will get submitted. The coordinator should post the announcement with details about what and how to do, where to submit the banners and then after a decided timeframe post the results back to the list. Of course we will accept new banners in the future, but for the initial batch it'd be nice to have some timeframe, since we already have a need. Eventually all the chosen banners will appear on the new mod_perl site. Since we are very close to the transition period, we need a temp location off-site for collecting the banners. Ideas for banners: * world domination chapter 1 (only 20% achieved) * world domination chapter 2 (50% target) * include the 2.0 theme * ... * definitely re-use the new logo http://wypug.digital-word.com/mod_perl/winner/ * ... Also I don't know if the banners can be animated or not. Someone who's in touch with the ads bussiness these days, please help the coordinator to fine tune the specs. p.s. I hope that I didn't make this simple thing sound too complicated :) p.p.s. could also in parallel run a T-shirt logo contest, we have a new conference coming up in July. It's definitely a time to start thinking about mod_perl freebies! p.p.p.s. You help is very appreciated! __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: framesets/AuthCookie question
Fran:
You may need to 1) add a few lines of code in AuthCookie to make your error
code aware to other methods, and 2) have a dynamic login page that can
interpret the code. Alternatively, you may try AccessCookie I posted. :-)
In AccessCookie, you simply return $error from authenticate(), let login
page() catch the code and display corresponding instruction. I haven't
tested it in a frame set, but it should appear a login page with custom
instructions in the last window the user visited before the expiration time.
The user re-types login/password, then is redirected to the page he tried
before.
Peter Bi
- Original Message -
From: Fran Fabrizio [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 17, 2002 3:01 PM
Subject: framesets/AuthCookie question
I'm using AuthCookie and as some of you know, if it determines your
session to be invalid it redirects to a login page instead by way of a
FORBIDDEN response coupled with a custom error page.
My app has a frameset (navigation on the left, and two data frames on
the right). I know the evils of framesets, but in our case, it's the
best way to present our particular data.
What ends up happening is that if the session expires, AuthCookie
displays the login page inside whatever frameset you were clicking in,
while the other two remain on whatever they were on previously.
I made a quick solution...I told AuthCookie that my login page was
login.html. login.html had javascript which called /real/login (a
mod_perl handler) and targeted it to the top frame. All is well and now
the entire browser window gets cleared and replaced with the login page.
However...I then thought it'd be neat to include on the /real/login page
a message to tell them how they got there (Your session has expired,
Your account has logged on from another location, Invalid
username/password combination, whatever...).
At first I thought I could accomplish this by simply doing
$r-notes('LOGINFAILMSG' = 'Your session has expired') if AuthCookie
detected it to be thus, and then in my handler I could retrieve it and
display it.
However, it's failing of course because I added the extra redirection of
the login.html w/ the javascript, which makes a round trip to the client
and back, so it looks like a brand new request to mod_perl, thus, no
notes() any more. Is there a solution to breaking out of the frameset
AND propagating the reason for the logout to the /real/login page?
I'd appreciate and and all ideas. Thanks!
-Fran
Re: Enforcing user logged in from only 1 browser?
Fran: 1) agreed. If a custom login page is needed, one has to look for other solutions such as cookie access control. 2) that depends. First, for some reasons, Internet is designed without Logout. Many seldom logout from those services such as Yahoo mail, and me too. For the specific question you posted (one login only for an account), while it can be in principle designed and implemented, in practice, it may not work that smoothly, because many users still don't run Logout. Trust me :-). So BA or cookie doesn't matter. Second, you can make a link to close the window using javascript, just like a Logout button. 3) will be very interesting to hear about your successful implementation! (BTW, if only the existence status of an account is needed to double check, please consider a lock file (e.g. -e) under Apache::File that may be much faster than to call SessionDBI) Peter - Original Message - From: Fran Fabrizio [EMAIL PROTECTED] To: Peter Bi [EMAIL PROTECTED] Cc: Jeff [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 6:33 AM Subject: Re: Enforcing user logged in from only 1 browser? Peter Bi wrote: If you touch SessionDBI for every request, why don't go directly to the Basic Authentication ? 1. You can't use a custom log in page 2. You can't log out unless you close your browser 3. It's for use by our employees only. They are told to enable cookies. =) -Fran
[ANNOUNCE Apache::AccessCookie-0.32] many new flavors
This is the second public release of the access control module. You can download it from here: http://mod_perl.home.att.net/AccessCookie_0_32.tar Besides few minor corrections from version 0.31, this one adds several ticket issuing mechanisms and the interface to implement new issuer is becoming especially easy to do. In details, here are they: 1) There is a default login page using the simply HTML codes. Webmasters can override the page() method according to the way they like. HTML::Template is not mandatory. 2) The ticket issuer module Apache::AccessCookieMaster, which uses DBI database, is now an interface named as Apache::AccessCookie::Ticket. To actually implement an issuing mechanism, one needs to inherits it and implement his/her own authenticate() method. Arguments to accepts are: $self, this; $r, the request object; $login, the login name; $password, the login password; and $last_access, when the user got a valid ticket last time. It returns an error string or undef if the issuer authentication is successsful. 3) Currently we have implemented the following 7 issuers: DBI: authenticated against a DBI database FTP: against a FTP server (those who can login to the FTP server gets a valid ticket) IMAP: against an IMAP server LDAP: against a LDAP server NIS: again a NIS server NISPlus: against a NIS+ plus server Remote: against a remote URL which is protected by Basic Authentication. 4) Because of the limitation to test all types of servers, PLEASE NOTE that IMAP, LDAP, NIS, NIS+ are actually in the 0.01 version and should be used very carefully. If you use them, please also take a look at the following related CPAN modules: Apache::AuthCookieLDAP Apache::AuthzLDAP Apache::AuthLDAP Apache::AuthenLDAP Apache::AuthNetLDAP Apache::AuthPerLDAP Apache::AuthenIMAP Apache::AuthenN2 Apache::AuthenNIS Apache::AuthzNIS Apache::AuthenNISPlus Authen::Smb Apache::AuthenNTLM Apache::AuthenSmb Apache::AuthenURL. Please help to improve the AccessCookie modules and send me a note! 5) For those who have not checked the last release nor other modules like Apache::AuthCookie, here is a short summary as what they are. Let's take the AccessCookie::Remote as an example. The original idea of authentication against a remote URL is in Apache-AuthenURL-0.8 (by John D Groenveld.): if a visitor can login successfully to a web page that is protected by Basic Authentication, he/she will be allowed to access the current site as well. In AuthenURL, the verification is performed by LWP that has to be made for every request. In the current ticketing system, the authentication is against a valid self-consistent ticket, a MD5 hash. If the visitor has no ticket, he/she is first redirected to the ticket master machine for getting a ticket. The ticket master (issuer) runs the module Apache::AccessCookie::Remote. It checks the credentials against the remote URL. If it passes, the master will issue a self-consistent ticket so the user can use the ticket for the following up requests within a limited time period. There is no need to verify against the remote URL every time. This should boost the speed very much. Peter Bi [EMAIL PROTECTED] Feb. 15, 2002
Re: Enforcing user logged in from only 1 browser?
To make a perfect system like this probably needs users to sign-off faithfully by every session. Peter Bi - Original Message - From: Fran Fabrizio [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 12, 2002 1:22 PM Subject: Enforcing user logged in from only 1 browser? Hello all, I'm looking for a straightforward approach to extend our AuthCookie sessioning to enforce that a user is only logged in from one browser at a time. For us, it would suffice that if the user tries to log in from a 2nd browser, the first session would just be expired. I was thinking that upon login I could save the AuthCookie key in that user's db entry as current_session_key and I could blank it out when they explicitly log out. Then during login, I would be able to see if there's another key still out there for them. The tricky part for me is figuring out if that key is still an -active- session as opposed to having just left their browser open last night or something. And also, if I do determine that it is another active one, how would I expire it? Anyone done this type of thing previously? Thanks, Fran
Re: Newbie Alert: Q: References to Authenticating a User to MS-SQL 2000?
Darren: you can subclass the authentication() method in the module AccessCookieMaster.pm I posted just a hour ago, if you won't mind asking your users enable cookies. ie: replacing select 1 from url_user.table where username='username' and password='password' by select 1 from ... AND url='$request_uri' For better control, you may need to double check the URL each time in AccessCookie.pm Peter Bi [EMAIL PROTECTED] - Original Message - From: Darren Ward [EMAIL PROTECTED] To: Apache-Perl (E-mail) [EMAIL PROTECTED] Sent: Monday, April 08, 2002 4:49 PM Subject: Newbie Alert: Q: References to Authenticating a User to MS-SQL 2000? Hi All, Subject line says it all really. I have a need to authenticate users against a MS-SQL 2000 Server which has a table with 'username' and 'password' fields but also on the Apache side need to be able to use a third field in the table 'url' to control what url's the user can access. The url field would be a one to many to the username. Any ideas? Darren Ward (PGradCS, CCIE #8245, CCNP, CCDP, MCP) Victorian Operations Manager Mobile: 0411 750 418 Email: [EMAIL PROTECTED] PGP Key: http://lithium.nttaus.com.au/~darrenw/darrenw.asc PGP Fingerprint: A4F9 3E93 4EE2 9CDF 5436 06EF 41B8 6027 4505 AE48 NTT Australia IP Pty Ltd ABN 73 080 394 645 Level M1, Rialto Towers 525 Collins Street, VIC. 3000 Tel: (03) 9683 0007 Fax: (03) 9620 7497 http://www.nttaus.com.au/IP/ -- -- - Australian General Telecommunications Carrier License No 23 -- -- - Disclaimer: Please note that this correspondence is for the named person's use only and may contain information that is confidential and privileged. If you received this correspondence in error, please immediately delete it from your system and notify the sender. Please ensure that you do not disclose, copy or rely on any part of this correspondence if you are not the intended recipient. We apologise for any inconvenience and thank you for your assistance.
