Re: Doing Authorization using mod_perl from a programmers perspective
Jon Robison wrote: > Someone please tell me if I am wrong - does the USER_AGENT field get > some kind of special serial number from the browser, or is it just a > version identified? > > Best example - large company with 1000 PC's, all with same Netscape > installed. How then does the HTTP_USER_AGENT field deliniate between > PC's? I've been out of town and am coming at this thread late. In case nobody else has mentioned it, HTTP_USER_AGENT values are 1) non- unique, and 2) often shared by applications on a single host (true especially for Microsoft environments). -- Richard Goerwitz [EMAIL PROTECTED] tel: 401 438 8978
Re: Doing Authorization using mod_perl from a programmers perspective
* Randal L. Schwartz ([EMAIL PROTECTED]) [09 11:00]: > > "Jon" == Jon Robison <[EMAIL PROTECTED]> writes: > > Jon> Randall, you want to expound upon that? > > Barely ignoring the spelling of my name, I'll simply claim > > "it's not unique". > > Neither is IP address. Or anything that you haven't specifically > round-tripped to the browser. And that doesn't stop someone from > making another browser respond in the same way, or that browser > respond in a different way. > > But this is obvious. I'm confused about why I'd have to explain it. :( > I think Randal has pointed out many times, as have others, that a browser isn't a person. One doesn't want to authenticate browsers, one wants to authenticate people. Using browser specific information to authenticate a person is not only impossible to do successfully, it is silly to try. Using cookies is only a little bit less unsuccessful. Also, please be sure to note the gotcha in the mod_perl guide that gives you warning that all browsers behave differently when dealing with a 401 status code. Be sure to take that into account. Thanks, JJ -- J. J. Horner "H*","6a686f726e657240326a6e6574776f726b732e636f6d" *** "H*","6a6a686f726e65724062656c6c736f7574682e6e6574" Freedom is an all-or-nothing proposition: either we are completely free, or we are subjects of a tyrannical system. If we lose one freedom in a thousand, we become completely subjugated. msg22686/pgp0.pgp Description: PGP signature
Re: Doing Authorization using mod_perl from a programmers perspective
On Mon, Nov 19, 2001 at 07:51:55AM -0800, Randal L. Schwartz wrote: > But this is obvious. I'm confused about why I'd have to explain it. :( I posted this a year or two back: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/jytwortwor/[EMAIL PROTECTED] Here is the relevant part of that post: It makes sense to start with the requirements for what it means to implement those secure features. My requirements have an obvious e-commerce bias, and should probably be heavily reviewed by anyone thinking of using this design for online banking or government work. First, I'd like to introduce the notion of a secure session. Secure sessions have some subtle differences from the traditional notion of the session, and I'll point those out when they appear. The secure session has the following properties: *) The user is able to initiate a secure session by providing proper credentials (i.e., a username and password pair) via a login process. *) The user is able to terminate the secure session via a logout process. *) Secure sessions must be able to time out automatically. *) Secure sessions must *never* transmit sensitive data (such as the password) over insecure channels. *) The secure session, while it requires the use of a secure protocol (such as HTTPS), should not require the use of cookies. Cookies, however, can be employed to extend the functionality of the system. Additionally, I feel that one of the essential requirements to any enterprise quality, highly scalable, and fault-tolerant system is the ability to store session state on a tier other than the front-end. This usually means storing state in a shared database, but there are other options. A very effective method of meeting the requirements above is to use a two token architecture. The first token is a user identifier, which can be passed over insecure channels. This user identification token can be used to restore state that isn't particularly sensitive, such as a shopping cart or user preferences. The second token is a secure identifier, which is never passed over insecure channels. The secure identifier is required to access sensitive data, such as credit card data. (It is possible to create an architecture that uses *only* the secure token, but there are significant benefits in terms of flexibility afforded by using two tokens, so I won't go into the one token model here.) The fundamental goal of the secure token is to a) keep it safe from prying eyes, and b) use it is a requirement for accessing secure data. Tokens can be passed in one of two ways. First, the token can be passed as part of the URL. Second, the token can be passed in a cookie. I've found it very useful to create an initialization procedure inside applications that check both places for these tokens, and abstract the particular mechanism used to pass them. Note, however, that is important to remember how the token was passed -- if it came from a cookie, it is cosmetic to not pass it around in the URL. I also recommend creating a library used in your templates that has a function to build URLs that automatically append the tokens if necessary. Since it is critical that secure tokens are never passed in the clear, it really helps to have that function, because it can prevent the secure token from being sent via an insecure page in a URL (i.e., only setting secure tokens in URLs that contain "https"). The user identification token is typically used to restore state from the database. It is created whenever a page is viewed and the client has either not provided one (via the URL or a cookie), or the token they provide doesn't exist in the database. This token should then be set in both the URL and in a cookie. On the subsequent page request, if the user identification token is found in a cookie, it is probably safe to stop putting it in the URL. However, if the token is found only in the URL (probably meaning the client does not use cookies) the server should not try writing the cookie again. The advantage of the cookie is such that the user can insecurely identify themselves across browser sessions. This is perfectly acceptable when used to restore some insensitive state data (such as a name or shopping cart). However, the system still functions without the cookie. The user can now login to associate their client with particular stored user information. The login process is as follows: 1) The client connects to a secure page that presents a form requesting a username and password. (There has been much discussion about whether a HTTP form that POSTS to a secure page will encrypt the posted data. There is too much ambiguity here -- I recommend using HTTPS on the login form as well.) The ACTION of the form must also be a secure page. 2) On receiving the username and password, the server compares an encrypted version of the password with the stored encrypted password associated with that customer. If the passwords do not matc
Re: Doing Authorization using mod_perl from a programmers perspective
> "Jon" == Jon Robison <[EMAIL PROTECTED]> writes: Jon> Randall, you want to expound upon that? Barely ignoring the spelling of my name, I'll simply claim "it's not unique". Neither is IP address. Or anything that you haven't specifically round-tripped to the browser. And that doesn't stop someone from making another browser respond in the same way, or that browser respond in a different way. But this is obvious. I'm confused about why I'd have to explain it. :( -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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: Doing Authorization using mod_perl from a programmers perspective
How about using an Apache::Sessions id instead of IP address? --Jon Robison "Randal L. Schwartz" wrote: > > > "fliptop" == fliptop <[EMAIL PROTECTED]> writes: > > fliptop> i have found that using the HTTP_USER_AGENT environment > fliptop> variable instead of ip address solves the problem with proxy > fliptop> servers and the md5 hash. anyone ever tried this as a simple > fliptop> workaround? > > Nobody with any sense. It's flawed. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[EMAIL PROTECTED]> 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: Doing Authorization using mod_perl from a programmers perspective
Randall, you want to expound upon that? --Jon Robison "Randal L. Schwartz" wrote: > > > "fliptop" == fliptop <[EMAIL PROTECTED]> writes: > > fliptop> i have found that using the HTTP_USER_AGENT environment > fliptop> variable instead of ip address solves the problem with proxy > fliptop> servers and the md5 hash. anyone ever tried this as a simple > fliptop> workaround? > > Nobody with any sense. It's flawed. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[EMAIL PROTECTED]> 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: Doing Authorization using mod_perl from a programmers perspective
> "fliptop" == fliptop <[EMAIL PROTECTED]> writes: fliptop> i have found that using the HTTP_USER_AGENT environment fliptop> variable instead of ip address solves the problem with proxy fliptop> servers and the md5 hash. anyone ever tried this as a simple fliptop> workaround? Nobody with any sense. It's flawed. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> 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: Doing Authorization using mod_perl from a programmers perspective
See. http://slashdot.org/articles/01/03/20/1423223.shtml On Fri, Nov 16, 2001 at 12:13:48PM -0500, Stephen Adkins wrote: > > FYI. > > This is true as a rule, that HTTP_USER_AGENT only identifies the > browser type, without a serial number. > > Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) > Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) > Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) > Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) > Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] > > However, I have seen in my web log the following user agents > > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::0510028001e00280014005060008 > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::2110028001e0025c00ea0503002a > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::2110028001e0027a01290505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::211003200258024b015f0505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::41100320025800c001b20505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::41100320025800c001b60505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::41100320025801f3018f0505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::4110032002580294011305020008 > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::411003200258031701860505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::411003200258031a018e0505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::411003200258031c019c05060008 > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::411003200258031e01aa0505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::411003200258032001b305060008 > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::41100400030003df020405060008 > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::81100320025802f901780505000b > > This indicates to me that some vendors who distribute MSIE 5.0 > on their PC's include some sort of ID in the HTTP_USER_AGENT > that the browser reports. (!?!) (privacy advocates beware!) > > Stephen > > > At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: > >The HTTP_USER_AGENT doesn't identify unique users. It only identifies the > >browser type/version (assuming it hasn't been messed with). > > > > > >--Joe Breeden > >--- > >If it compiles - Ship It! > >Aranea Texo > > > >> -----Original Message- > >> From: Jon Robison [mailto:[EMAIL PROTECTED]] > >> Sent: Friday, November 16, 2001 10:40 AM > >> To: [EMAIL PROTECTED] > >> Cc: Jonathan E. Paton; [EMAIL PROTECTED] > >> Subject: Re: Doing Authorization using mod_perl from a programmers > >> perspective > >> > >> > >> fliptop wrote: > >> > > >> > Jon Robison wrote: > >> > > > >> > > The most relevant section for you is the Ticket system he > >> describes. (I > >> > > believe the section header says something about Cookies, > >> but you'll know > >> > > you have the right one when you see TicketAccess.pm, > >> TicketTools.pm, and > >> > > TicketMaster.pm. One nice addition is the ability to add > >> encryption to > >> > > the Ticket, and the fact that the author used an MD5 hash > >> (of an MD5 > >> > > hash!) in the cookie, so verification of the authenticity > >> of the user is > >> > > pretty solid so long as you leave in things like ip > >> address, etc. which > >> > > he uses in the cookie by default. (Although AOL and some > >> proxy systems > >> > > might cause this to be trouble). AND, he also uses a > >> mysql db for the > >> > > >> > i have found that using the HTTP_USER_AGENT environment > >> variable instead > >> > of ip address solves the problem with proxy servers and the > >> md5 hash. > >> > anyone ever tried this as a simple workaround? > >> > >> I think one problem with that is that is fails to uniquely > >> identify the > >> person. > >> > >> Someone please tell me if I am wrong - does the USER_AGENT field get > >> some kind of special serial number from the browser, or is it just a > >> version identified? > >> > >> Best example - large company with 1000 PC's, all with same Netscape > >> installed. How then does the HTTP_USER_AGENT field deliniate between > >> PC's? > >> > >> --Jon > >> > > > > >
Re: Doing Authorization using mod_perl from a programmers perspective
See. http://slashdot.org/articles/01/03/20/1423223.shtml On Fri, Nov 16, 2001 at 12:13:48PM -0500, Stephen Adkins wrote: > > FYI. > > This is true as a rule, that HTTP_USER_AGENT only identifies the > browser type, without a serial number. > > Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) > Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) > Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) > Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) > Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] > > However, I have seen in my web log the following user agents > > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::0510028001e00280014005060008 > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::2110028001e0025c00ea0503002a > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::2110028001e0027a01290505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::211003200258024b015f0505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::41100320025800c001b20505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::41100320025800c001b60505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::41100320025801f3018f0505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::4110032002580294011305020008 > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::411003200258031701860505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::411003200258031a018e0505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::411003200258031c019c05060008 > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::411003200258031e01aa0505000b > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::411003200258032001b305060008 > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::41100400030003df020405060008 > Mozilla/4.0 (compatible; MSIE 5.0; Windows > 95)::ELNSB50::81100320025802f901780505000b > > This indicates to me that some vendors who distribute MSIE 5.0 > on their PC's include some sort of ID in the HTTP_USER_AGENT > that the browser reports. (!?!) (privacy advocates beware!) > > Stephen > > > At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: > >The HTTP_USER_AGENT doesn't identify unique users. It only identifies the > >browser type/version (assuming it hasn't been messed with). > > > > > >--Joe Breeden > >--- > >If it compiles - Ship It! > >Aranea Texo > > > >> -----Original Message- > >> From: Jon Robison [mailto:[EMAIL PROTECTED]] > >> Sent: Friday, November 16, 2001 10:40 AM > >> To: [EMAIL PROTECTED] > >> Cc: Jonathan E. Paton; [EMAIL PROTECTED] > >> Subject: Re: Doing Authorization using mod_perl from a programmers > >> perspective > >> > >> > >> fliptop wrote: > >> > > >> > Jon Robison wrote: > >> > > > >> > > The most relevant section for you is the Ticket system he > >> describes. (I > >> > > believe the section header says something about Cookies, > >> but you'll know > >> > > you have the right one when you see TicketAccess.pm, > >> TicketTools.pm, and > >> > > TicketMaster.pm. One nice addition is the ability to add > >> encryption to > >> > > the Ticket, and the fact that the author used an MD5 hash > >> (of an MD5 > >> > > hash!) in the cookie, so verification of the authenticity > >> of the user is > >> > > pretty solid so long as you leave in things like ip > >> address, etc. which > >> > > he uses in the cookie by default. (Although AOL and some > >> proxy systems > >> > > might cause this to be trouble). AND, he also uses a > >> mysql db for the > >> > > >> > i have found that using the HTTP_USER_AGENT environment > >> variable instead > >> > of ip address solves the problem with proxy servers and the > >> md5 hash. > >> > anyone ever tried this as a simple workaround? > >> > >> I think one problem with that is that is fails to uniquely > >> identify the > >> person. > >> > >> Someone please tell me if I am wrong - does the USER_AGENT field get > >> some kind of special serial number from the browser, or is it just a > >> version identified? > >> > >> Best example - large company with 1000 PC's, all with same Netscape > >> installed. How then does the HTTP_USER_AGENT field deliniate between > >> PC's? > >> > >> --Jon > >> > > > > >
RE: Doing Authorization using mod_perl from a programmers perspective
FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: >The HTTP_USER_AGENT doesn't identify unique users. It only identifies the >browser type/version (assuming it hasn't been messed with). > > >--Joe Breeden >--- >If it compiles - Ship It! >Aranea Texo > >> -Original Message- >> From: Jon Robison [mailto:[EMAIL PROTECTED]] >> Sent: Friday, November 16, 2001 10:40 AM >> To: [EMAIL PROTECTED] >> Cc: Jonathan E. Paton; [EMAIL PROTECTED] >> Subject: Re: Doing Authorization using mod_perl from a programmers >> perspective >> >> >> fliptop wrote: >> > >> > Jon Robison wrote: >> > > >> > > The most relevant section for you is the Ticket system he >> describes. (I >> > > believe the section header says something about Cookies, >> but you'll know >> > > you have the right one when you see TicketAccess.pm, >> TicketTools.pm, and >> > > TicketMaster.pm. One nice addition is the ability to add >> encryption to >> > > the Ticket, and the fact that the author used an MD5 hash >> (of an MD5 >> > > hash!) in the cookie, so verification of the authenticity >> of the user is >> > > pretty solid so long as you leave in things like ip >> address, etc. which >> > > he uses in the cookie by default. (Although AOL and some >> proxy systems >> > > might cause this to be trouble). AND, he also uses a >> mysql db for the >> > >> > i have found that using the HTTP_USER_AGENT environment >> variable instead >> > of ip address solves the problem with proxy servers and the >> md5 hash. >> > anyone ever tried this as a simple workaround? >> >> I think one problem with that is that is fails to uniquely >> identify the >> person. >> >> Someone please tell me if I am wrong - does the USER_AGENT field get >> some kind of special serial number from the browser, or is it just a >> version identified? >> >> Best example - large company with 1000 PC's, all with same Netscape >> installed. How then does the HTTP_USER_AGENT field deliniate between >> PC's? >> >> --Jon >> > >
RE: Doing Authorization using mod_perl from a programmers perspective
The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo > -Original Message- > From: Jon Robison [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 16, 2001 10:40 AM > To: [EMAIL PROTECTED] > Cc: Jonathan E. Paton; [EMAIL PROTECTED] > Subject: Re: Doing Authorization using mod_perl from a programmers > perspective > > > fliptop wrote: > > > > Jon Robison wrote: > > > > > > The most relevant section for you is the Ticket system he > describes. (I > > > believe the section header says something about Cookies, > but you'll know > > > you have the right one when you see TicketAccess.pm, > TicketTools.pm, and > > > TicketMaster.pm. One nice addition is the ability to add > encryption to > > > the Ticket, and the fact that the author used an MD5 hash > (of an MD5 > > > hash!) in the cookie, so verification of the authenticity > of the user is > > > pretty solid so long as you leave in things like ip > address, etc. which > > > he uses in the cookie by default. (Although AOL and some > proxy systems > > > might cause this to be trouble). AND, he also uses a > mysql db for the > > > > i have found that using the HTTP_USER_AGENT environment > variable instead > > of ip address solves the problem with proxy servers and the > md5 hash. > > anyone ever tried this as a simple workaround? > > I think one problem with that is that is fails to uniquely > identify the > person. > > Someone please tell me if I am wrong - does the USER_AGENT field get > some kind of special serial number from the browser, or is it just a > version identified? > > Best example - large company with 1000 PC's, all with same Netscape > installed. How then does the HTTP_USER_AGENT field deliniate between > PC's? > > --Jon >
Re: Doing Authorization using mod_perl from a programmers perspective
fliptop wrote: > > Jon Robison wrote: > > > > The most relevant section for you is the Ticket system he describes. (I > > believe the section header says something about Cookies, but you'll know > > you have the right one when you see TicketAccess.pm, TicketTools.pm, and > > TicketMaster.pm. One nice addition is the ability to add encryption to > > the Ticket, and the fact that the author used an MD5 hash (of an MD5 > > hash!) in the cookie, so verification of the authenticity of the user is > > pretty solid so long as you leave in things like ip address, etc. which > > he uses in the cookie by default. (Although AOL and some proxy systems > > might cause this to be trouble). AND, he also uses a mysql db for the > > i have found that using the HTTP_USER_AGENT environment variable instead > of ip address solves the problem with proxy servers and the md5 hash. > anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
RE: Doing Authorization using mod_perl from a programmers perspective
> > > my point > > was that this solves the problem of using the ip address in > the md5 hash > > when the client is behind a proxy server. > > This does not solve the problem: IP address of users behind > Proxy is not > unique. The User Agent is not unique either. Using User Agent solves > nothing, and is in fact far less secure, since the client can > set the User > Agent header to be just about anything. At least the IP > address has to be > correct (but not unique) if the client wants to get a response. the IP address is really a poor choice if I understand AOL and other large-scale proxies enough - they use a round-robin IP scheme where multiple requests _from the same user_ can appear as different IP addresses. the cool thing about the MD5 hashing scheme is that any would-be hacker needs to know the fields you are hashing in order to have a chance at creating a like hash. so, if you use stuff transmitted in the clear (like username, sessionid, some bogus piece of info not used, and MD5 hash) as well as other stuff obtainable from the transaction (like user-agent, protocol, method, accept header) and combine some random form of these (along with a server-side-only secret) the hash should be reasonably secure. this is kind of how digest authentication works (except there the algorithm is published, so you know the parameters involved). --Geoff
Re: Doing Authorization using mod_perl from a programmers perspective
Joe Breeden wrote: > > How does this work in an environment with two (or more) computers with the > exact same configuration, and probably the same HTTP_USER_AGENT behind the > same proxy? How do you know that one user isn't using another users session? you don't. the session hijacker still would need to know the real user's username, password, and HTTP_USER_AGENT configuration. my point was that this solves the problem of using the ip address in the md5 hash when the client is behind a proxy server.
RE: Doing Authorization using mod_perl from a programmers perspective
How does this work in an environment with two (or more) computers with the exact same configuration, and probably the same HTTP_USER_AGENT behind the same proxy? How do you know that one user isn't using another users session? --Joe Breeden --- If it compiles - Ship It! Aranea Texo > -Original Message- > From: fliptop [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 15, 2001 4:50 PM > To: Jon Robison > Cc: Jonathan E. Paton; [EMAIL PROTECTED] > Subject: Re: Doing Authorization using mod_perl from a programmers > perspective > > > Jon Robison wrote: > > > > The most relevant section for you is the Ticket system he > describes. (I > > believe the section header says something about Cookies, > but you'll know > > you have the right one when you see TicketAccess.pm, > TicketTools.pm, and > > TicketMaster.pm. One nice addition is the ability to add > encryption to > > the Ticket, and the fact that the author used an MD5 hash (of an MD5 > > hash!) in the cookie, so verification of the authenticity > of the user is > > pretty solid so long as you leave in things like ip > address, etc. which > > he uses in the cookie by default. (Although AOL and some > proxy systems > > might cause this to be trouble). AND, he also uses a mysql > db for the > > i have found that using the HTTP_USER_AGENT environment > variable instead > of ip address solves the problem with proxy servers and the md5 hash. > anyone ever tried this as a simple workaround? >
Re: Doing Authorization using mod_perl from a programmers perspective
Jon Robison wrote: > > The most relevant section for you is the Ticket system he describes. (I > believe the section header says something about Cookies, but you'll know > you have the right one when you see TicketAccess.pm, TicketTools.pm, and > TicketMaster.pm. One nice addition is the ability to add encryption to > the Ticket, and the fact that the author used an MD5 hash (of an MD5 > hash!) in the cookie, so verification of the authenticity of the user is > pretty solid so long as you leave in things like ip address, etc. which > he uses in the cookie by default. (Although AOL and some proxy systems > might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround?
Re: Doing Authorization using mod_perl from a programmers perspective
Jonathon,
I am doing exactly this also. What works is this:
Get a copy of "Writing Apache modules with perl and C" and read it.
The most relevant section for you is the Ticket system he describes. (I
believe the section header says something about Cookies, but you'll know
you have the right one when you see TicketAccess.pm, TicketTools.pm, and
TicketMaster.pm. One nice addition is the ability to add encryption to
the Ticket, and the fact that the author used an MD5 hash (of an MD5
hash!) in the cookie, so verification of the authenticity of the user is
pretty solid so long as you leave in things like ip address, etc. which
he uses in the cookie by default. (Although AOL and some proxy systems
might cause this to be trouble). AND, he also uses a mysql db for the
passwords, etc. All in all, a VERY usefull section of the book.
As for "pushing content" after authorization, take a very close look at
the $r->push_handler() function. I use it like this:
my $input = $r->args (or however you want to get input - Apache::Request
is a good way)
if (defined $input->{some_param}) {
$r->push_handler( PerlHandler => MyActionModule );
} else {
$r->push_handler(PerlHandler => MyErrorModule );
}
Because the request object (usually $r) exists in it's same state when
the new PerlHandler is called, grabbing $input again (via whatever
method) can be used to determine what action the module takes.
This isn't precise, so please read the manual before using this, but you
get the idea. One thing to keep in mind is that perl_handlers
(PerlHandler) is a stack that will draw from the top, so it is FILO, not
FIFO.
Hope this helps.
Jonathon Robison
Uniphied Thought, LLC.
"Jonathan E. Paton" wrote:
>
> I am trying to create a website with predominantly dynamic
> content (mod_perl + DBI + mySQL) for an online community.
> I can manage Perl and mySQL fairly proficently, however
> I've no idea how to successfully create what I want using
> mod_perl and Apache (actually, I know next to nothing about
> them).
>
> --- Background information ---
>
> The website shall be split into a public and private
> section, and will share a common layout and appearance
> (although I might add little visual clues to indicate which
> section they are in). When members wish to login I want
> them to do so via the public section (from that page), and
> then be able to access the additional links/features of the
> private section.
>
> I wish to handle all the database actions in my own code,
> unless something fits perfectly. When members try to
> login, my aims are:
>
> 1. Check login name, and password.
> 2. Check member hasn't been suspended.
> 3. Return the membership ID number for the next stage.
>
> The membership ID number will be used to decide what access
> level the members have (what forums, tools etc they can see
> and use). The SQL table is specified as:
>
> CREATE TABLE access (
> member_id int(10) unsigned NOT NULL,
> account_name varchar(16) NOT NULL,
> account_password varchar(16) NOT NULL,
> state enum('A', 'S') DEFAULT 'A' NOT NULL,
>
> PRIMARY KEY (account_name)
> );
>
> Imagine I now create an object to wrap around this, with
> the following method:
>
> my $permission = $access->check($account_name,
> $account_password);
>
> which returns the membership number if valid,
> or the value -1 for a suspended account,
> or undef for no account.
>
> --- Questions ---
>
> 1. Can this be done (nicely) as a
> authentication/authorization handlier?
>
> 2. Do most hosting companies allow
> authentication/authorization handlers? (Using HostRocket
> at the moment).
>
> 3. What is the most appropriate session management system?
> I'm thinking of using cookies (client side) to store a
> session key, rather than resubmitting the password data.
> The server side stores this session key in the database.
>
> 4. How does the membership ID get passed to the next stage?
>
> 5. What is the time to do additional access checking (for
> senior/admin users)? I was planning to do it a little
> later on, but it is probably better to do it once (i.e.
> with this).
>
> 6. What is a realistic time to expect all this to happen
> in?
>
> I'm sure I've missed a few questions...
>
> Any help appriecated, especially links to relevent
> documentation.
>
> Jonathan Paton
>
> NB - Whilst my preferred answer to these questions is a
> coded solution, I have a restriction (self imposed) - I'd
> prefer to have full copyright on the final code, thus I ask
> any major ideas/code includes permission to use it freely -
> or else be good enough to be worth adding your name provide
> I use it :)
>
> __
> Do You Yahoo!?
> Everything you'll ever need on one web page from News and Sport to Email and Music
>Charts
> http://uk.my.yahoo.com
Re: Doing Authorization using mod_perl from a programmers perspective
"Jonathan E. Paton" <[EMAIL PROTECTED]> writes: > Please don't flame me, I'll go away... honest :P I wonder if you're trying to do too much too soon? If you're concerned about hosting then *gulp* PHP might server you better. I rent a dedicated server because I want absolute control and the ability to run my own handler. -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Deep Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
Re: Doing Authorization using mod_perl from a programmers perspective
> Seemingly I can do Apache handlers though, so I *might* be > okay. If you look at http://perl.apache.org/guide/, there's information on how to determine if you're really running mod_perl or not. If you can get a PerlHandler directive to work, you have mod_perl. > I rather ambigously asked the question: How many > milliseconds might this stage take, on a commerial hosting > company's servers. Suppose without mod_perl this would be > at least 300ms, or probably worse. It depends on what you're doing in that stage. In relative terms, programs that access databases usually run many times faster in mod_perl than with CGI. - Perrin
Re: Doing Authorization using mod_perl from a programmers perspective
Hi, > > Perrin Harkins wrote: > > > > 2. Do most hosting companies allow > > authentication/authorization handlers? (Using > > HostRocket at the moment). > > Most hosting companies don't allow mod_perl. > I had fears about that one, since I thought Perl might not mean mod_perl - as I know mod_perl is rather cosy with Apache (that's the whole point). With the functionality I had in mind it'd take too long to compile them on the fly. Seemingly I can do Apache handlers though, so I *might* be okay. Looks like I may have to run it off my friends ADSL connection, as I'm stuck in 56k hell. That adds nice domain redirection and uptime problems (of ADSL) to my life ;-) > > 6. What is a realistic time to expect all this > > to happen in? > > Also impossible to answer, since it depends on your > developers and the full requirements. My developers? - What's a developer? :P The best I've got are inexperienced amatures with relevatively little coding experience with Perl. Tough challenge eh? With some determination we'll get it finished by Christmas (not this year :P ) I rather ambigously asked the question: How many milliseconds might this stage take, on a commerial hosting company's servers. Suppose without mod_perl this would be at least 300ms, or probably worse. > > Ged Haywood wrote: > > I am trying to create a website [snip] > > NB - Whilst my preferred answer to these questions is a > > coded solution, [snip] > > We like people to think for themselves on this list. :) Okay, I forgot the smiley on that. I don't really expect anyone to code it for me, that's asking too much... unless people are willing to share what they've already done. I'd owe someone too many brownie points if they coded it for me. The "Background" was there for interest really, and to suggest what I'm trying to do. Please don't flame me, I'll go away... honest :P Jonathan Paton __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: Doing Authorization using mod_perl from a programmers perspective
> 1. Can this be done (nicely) as a > authentication/authorization handlier? Sure, or you could do it as part of another phase if it's easier for you. There are good exmples on CPAN or in the Eagle book. > 2. Do most hosting companies allow > authentication/authorization handlers? (Using HostRocket > at the moment). Most hosting companies don't allow mod_perl. > 3. What is the most appropriate session management system? > I'm thinking of using cookies (client side) to store a > session key, rather than resubmitting the password data. > The server side stores this session key in the database. That sounds fine. There are examples of this in the book too. Make sure your session keys can't be forged. > 4. How does the membership ID get passed to the next stage? It's typically stored in the session data. > 5. What is the time to do additional access checking (for > senior/admin users)? Impossible to answer. Totally depends on your setup. > 6. What is a realistic time to expect all this to happen > in? Also impossible to answer, since it depends on your developers and the full requirements. - Perrin
Re: Doing Authorization using mod_perl from a programmers perspective
Hi there, On Wed, 14 Nov 2001, [iso-8859-1] Jonathan E. Paton wrote: > I am trying to create a website [snip] > NB - Whilst my preferred answer to these questions is a > coded solution, [snip] We like people to think for themselves on this list. :) > I'm sure I've missed a few questions... Read http://perl.apache.org/guide and "Writing Apache Modules with Perl and C", ISBN 1-56592-567-X (otherwise known as the "Eagle Book") which will answer almost all the questions you can think of, and a great many that you can't (yet). Some of your questions have no answer. Please don't ask questions that are answered in these publications on this list, people here have a habit of directing you to them for guidance. This implies a lot of patience on your part, because they are fairly lengthy and concentrated technical works, and not much patience on our part (for whatever reasons :). Despite the quip about thinking people above, there are lots of coded solutions in these books which you can adapt or otherwise mangle. TMTOWTDI y'know. 73, Ged.
Doing Authorization using mod_perl from a programmers perspective
I am trying to create a website with predominantly dynamic
content (mod_perl + DBI + mySQL) for an online community.
I can manage Perl and mySQL fairly proficently, however
I've no idea how to successfully create what I want using
mod_perl and Apache (actually, I know next to nothing about
them).
--- Background information ---
The website shall be split into a public and private
section, and will share a common layout and appearance
(although I might add little visual clues to indicate which
section they are in). When members wish to login I want
them to do so via the public section (from that page), and
then be able to access the additional links/features of the
private section.
I wish to handle all the database actions in my own code,
unless something fits perfectly. When members try to
login, my aims are:
1. Check login name, and password.
2. Check member hasn't been suspended.
3. Return the membership ID number for the next stage.
The membership ID number will be used to decide what access
level the members have (what forums, tools etc they can see
and use). The SQL table is specified as:
CREATE TABLE access (
member_id int(10) unsigned NOT NULL,
account_name varchar(16) NOT NULL,
account_password varchar(16) NOT NULL,
state enum('A', 'S') DEFAULT 'A' NOT NULL,
PRIMARY KEY (account_name)
);
Imagine I now create an object to wrap around this, with
the following method:
my $permission = $access->check($account_name,
$account_password);
which returns the membership number if valid,
or the value -1 for a suspended account,
or undef for no account.
--- Questions ---
1. Can this be done (nicely) as a
authentication/authorization handlier?
2. Do most hosting companies allow
authentication/authorization handlers? (Using HostRocket
at the moment).
3. What is the most appropriate session management system?
I'm thinking of using cookies (client side) to store a
session key, rather than resubmitting the password data.
The server side stores this session key in the database.
4. How does the membership ID get passed to the next stage?
5. What is the time to do additional access checking (for
senior/admin users)? I was planning to do it a little
later on, but it is probably better to do it once (i.e.
with this).
6. What is a realistic time to expect all this to happen
in?
I'm sure I've missed a few questions...
Any help appriecated, especially links to relevent
documentation.
Jonathan Paton
NB - Whilst my preferred answer to these questions is a
coded solution, I have a restriction (self imposed) - I'd
prefer to have full copyright on the final code, thus I ask
any major ideas/code includes permission to use it freely -
or else be good enough to be worth adding your name provide
I use it :)
__
Do You Yahoo!?
Everything you'll ever need on one web page from News and Sport to Email and Music
Charts
http://uk.my.yahoo.com
