RE: Cookie-free authentication
hi all www.wgsn.com is a subscription based service that doesn't use cookies for authentication. we use basic auth. I would like to share what i consider "how not to implement cookie-free authentication". there are three tiers to our website tier 1 is apache with mod_perl doing authentication and mod_proxy passing requests to tier 2 tier 2 is a content management server tier 3 is the database server. tier 3 stores the raw content, tier 2 puts the bits from the db server together and tier 1 logs the hit and sends it to the client, nothing too fancy here. our authentication has two main bits that suck. first is subscribers have their username and password mapped to a special username and password for the content management systems, which differs on varying levels of subscriptions. as an example, the apache servers may recognize n valid usernames and passwords, while the cms only recognizes 3. this mapping is done via an apache module written in perl, which talks to a series of perl scripts that keep a copy of the user database. when a request comes in to the apache servers, the module maps the customer username/pass to the content management username/pass, rewrites the Authorization: header, and mod_proxy sends the request to tier 2. this sounds reasonably simple, but in the real world it's one big bit of mush of unpleasant stuff that falls over every other week. why that is i've never been able to exactly put my finger on, but i have a feeling it was developers letting their personal preferences getting in the way of business needs, by ignoring existing standards or best practices, and going out to re-invent a better wheel. the second (and imo bigger) bit that sucks is because we do silly things like re-writing incoming http headers and cleaning them as the response goes back out, we can't utilize things like caching as effectively as we could if we were using cookies. the reason for this is due to our requirement that we must see which users are accessing which areas of the site (so we can see what's popular etc). The information we require is stored in these re-written headers. This means we need our downstream caching hierarchy (which is a 3rd party) to send at least an If-Modified-Since request for images (some of which we allow to be cached), and we cannot allow them to cache our html documents. If we used cookies our caches could authenticate & log hits at the caching server nearest the client instead of having to come back to our origin servers for every single hit. in busy periods we serve around 2.5 million objects a day, nothing really major, but enough to make things like this a significant drain on our resources (which are limited as always :) for the reasons above, we are investigating the transition to cookie based authentication. i suppose it really depends on what you are developing, but take heed. i fully understand why cookie based authentication may be unacceptable, but consider maintainability and (long-term) scalability when you're doing your design and implementation. in the end you'll save someone a few grey hairs :) -pete > -Original Message- > From: Geoffrey Young [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 12, 2002 1:44 PM > To: Ron Savage > Cc: Apache mod_perl > Subject: Cookie-free authentication > > > > > Ron Savage wrote: > > On Wed, 11 Dec 2002 13:58:18 -0700, Nathan Torkington wrote: > > > [snip] > > > > Some of us are trying to implement > authentication/login/logout where, > > if at all possible, cookies are not to be used. A cookie-free > > discussion would be most welcome. > > I've done a bit of preliminary work with using Digest > authentication to accomplish this - > see Session.pm in Apache::AuthDigest, the latest copy of > which can be found here > > http://www.modperlcookbook.org/~geoff/modules/Apache-AuthDiges > t-0.022.tar.gz > > it's fairly new interface, and I've only toyed with it > (though there is _some_ > documentation :). however, it seems to me that (for clients > that can support this > implementation of Digest, which seems to be just about > everyone but MSIE) the nonce > provides exactly the kind of state information that is > required for login/logout > authentication. > > of course, it trades cookies for that pop-up box (again), so > if you're looking for > cookiless, HTML form based logins, then it's probably not > what you want. > > --Geoff >
RE: How to see debug information in Net::Smtp?
its bitten me in the ass a few times before, just thought id mention it cheers -pete -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 1:29 PM To: Peter Werner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: How to see debug information in Net::Smtp? Peter Werner wrote: > and set your LogLevel to debug why? after all he is talking about perl logging, not Apache. LogLevel has nothing to do with it. > -Original Message- > From: Stas Bekman [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 17, 2002 10:27 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: How to see debug information in Net::Smtp? > > > [EMAIL PROTECTED] wrote: > >>I use Net::Smtp module in my mod_perl script. When I run the >>fragment of my code from command line I can see the debug info. >>But running it on the production server I can't see the debug >>information. >> >>What can I do to see the debug info on the production server? > > > look in the error_log file? > > > > __ > 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 -- __ 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: How to see debug information in Net::Smtp?
and set your LogLevel to debug -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 10:27 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to see debug information in Net::Smtp? [EMAIL PROTECTED] wrote: > I use Net::Smtp module in my mod_perl script. When I run the > fragment of my code from command line I can see the debug info. > But running it on the production server I can't see the debug > information. > > What can I do to see the debug info on the production server? look in the error_log file? __ 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: mod_perl help
make sure you are not using the sun as and ld etc. you can check by looking at the output of "which as". (should be /usr/local/bin/as not /usr/ccs/bin/as). i have /usr/local/bin in my PATH before /usr/ccs/bin and /usr/ucb. if this doesnt help i would try recompiling perl. maybe someone with more knowledge of the subject could explain why mod_perl needs perl to be compiled with the same compiler (just idle curiosity) cheers -pete -Original Message- From: Ryan Hairyes [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 11, 2002 4:45 PM To: Peter Werner Cc: [EMAIL PROTECTED] Subject: RE: mod_perl help Thanks for the reply. Actually ... according to sunfreeware perl5.6.1 was compiled with gcc. Anything else you can think of? Thanks again. Quoting Peter Werner <[EMAIL PROTECTED]>: : you will have to compile perl from scratch as the sunfreeware perl is : compiled with suns compiler not gcc and this causes problems. poke around : sunfreeware.com for the instructions he used to build perl, it is quite : simple. : : -pete : : -Original Message- : From: Ryan Hairyes [mailto:[EMAIL PROTECTED]] : Sent: Thursday, July 11, 2002 4:34 PM : To: [EMAIL PROTECTED] : Subject: mod_perl help : : : Hello all, : : I just compiled mod_perl 1.27 with apache 1.3 for Solaris 8. I used perl : 5.6.1 and gcc from www.sunfreeware.com. After I compiled everything and : tried : to load the perl module (with LoadModule) I receive the following error: : : : Cannot load /usr/local/apache/libexec/libperl.so into server: ld.so.1: : /usr/local/apache/sbin/httpd: fatal: relocation error: file : /usr/local/apache/libexec/libperl.so: symbol main: referenced symbol not : found : : : Any idea on what I did wrong? Thanks. : : Ryan : -- Ryan Hairyes Network/System Administration Lee County School System Phone:919.774.6226 x 1252 Voicemail:x 2361
RE: Commercial use of mod_perl / modules
ask a lawyer. if you get taken to court "but some guy on some mailing list said it was ok" is not a great defence. all: can we please not turn this thread into a million and one personal interpretations of the situation. unless you are qualified to give a legal advice, you are just creating list fluff and wasting bandwidth. -pete -Original Message- From: Kirk Bowe [mailto:[EMAIL PROTECTED]] Sent: Friday, June 28, 2002 11:30 AM To: [EMAIL PROTECTED] Subject: Commercial use of mod_perl / modules I've been asked an interesting (though apologies if this is a heated or irelevant topic) question: what's the legality of using mod_perl (and indeed Apache), and the available modules, in a non-GPL commercial application for which there is a charge? I can't think of any modules off hand that are GPLd (most of the ones I've come across tend to say "this is freeware, you're free to use it as you wish so long as you preserve my copyright message", etc.). As far as I can see, therefore, it is fine to use Apache and most of the perl modules (if they're not GPLd), as supporting tools, in a commercial project without paying for, or infringing, any authors's rights. So long, I guess, as you make it clear that there is no charge for Apache or any of the associated perl modules that you use in that project, and produce a list of all the individual authors' copyright notices. Sorry -- don't want to turn this into a long thread about commercialism versus "freedom" -- just wondering if there is a clear stance on the issue. Cheers Kirk.
