You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Vladimir S. Tikhonjuk" <vs...@vst.donetsk.ua> on 2006/08/03 13:51:58 UTC
Authentication
Hi all!
I'm thinking about 2 methods of authentication users for my site.
May be you'll help me to choose one of them, or advice me something else.
The first method: using PerlAuthenHandler on '/' Location.
The second method: simple handler, for example
http://localhost/login, which checks login and password, If everything
is O.K. make session, send cookie with session id. And another handler
which checks every reqest for Cookie with session id and desided whether
to give access or not.
Disadvantage (as I think) of first method: before every request make
SQL query to the database for varification login and password.
Best regards,
Vladimir
Re: Authentication
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Radoslaw Zielinski wrote:
> With persistent database connections and prepared statements it doesn't
> hurt that much in terms of performance. Just make sure you're not
> checking what you don't have to (images, *.css, etc).
>
Which is why (we) generally suggest that you don't setup handlers on Location /. It generally is more trouble then its
worth, but is useful from time-to-time.
See the 2 attachments for an example.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
Re: Authentication
Posted by Jonathan <jv...@2xlp.com>.
On Aug 5, 2006, at 6:07 AM, Radoslaw Zielinski wrote:
> Thanks for explaining, I wasn't aware of cases like this. For some
> reason, I thought you mean clients on some crazy PPP link which breaks
> once every few minutes.
yeah, its extremely common with ISPs in the US.
its also common with businesses: In the past I've worked in a number
of offices that use similar systems : a T1 , coupled with a cable
modem installed as backup (not dsl, as the same company handles the
local loop for t1 and dsl, so it can't be used as backup), are linked
to an internal gateway / firewall that load-balances requests into
both connections.
Re: Authentication
Posted by Radoslaw Zielinski <ra...@gmail.com>.
Jonathan Vanasco <mo...@2xlp.com> [04-08-2006 18:07]:
[ ... context: storing client's IP in the
session and checking if it's the same ]
> internally, my ip doesn't change- and lengty connections are fine.
> but every new request goes through a different transparent proxy (
> dialup109.aol.com, dialup200f.aol.com , etc )
Thanks for explaining, I wasn't aware of cases like this. For some
reason, I thought you mean clients on some crazy PPP link which breaks
once every few minutes.
--
Radosław Zieliński <ra...@pld-linux.org>
Re: Authentication
Posted by Jonathan Vanasco <mo...@2xlp.com>.
On Aug 4, 2006, at 8:06 AM, Issac Goldstand wrote:
> Not necessarily so. Like Jonathan mentioned, many huge ISPs (like
> AOL,
> for example, IIRC) route requests through load balanced transparent
> proxies. This can cause the same person to appear to browse from a
> number of different IPs - changing perhaps even more often than
> Jonathan
> reported.
>
>> Uh, that's extreme. But I'd call it a broken network, not a problem
>> with the idea of matching IP. With something like this, any service
>> using long-lasting connections will have problems.
Yea. For example, the 192.168.1.x network is my isp. i connect to
it, get an internal 10.0.1.1 address.
8:00am - http request funneled through 192.168.1.1
8:01am - http request funneled through 192.168.1.2
8:02am - http request funneled through 192.168.1.3
8:03am - ftp transfer funneled through 192.168.1.100
8:04am - http request funneled through 192.168.1.3 -- ftp still going
internally, my ip doesn't change- and lengty connections are fine.
but every new request goes through a different transparent proxy
( dialup109.aol.com, dialup200f.aol.com , etc )
i don't use aol. i just see tons of stuff like that in my click-
visit logs
sometimes isps are nice and will do some internal stuff so that all
requests go through a common proxy ( map a hash of user/domain onto a
server? or actually track who uses what? i dunno ). but i wouldn't
count on that.
Re: Authentication
Posted by Issac Goldstand <ma...@beamartyr.net>.
Not necessarily so. Like Jonathan mentioned, many huge ISPs (like AOL,
for example, IIRC) route requests through load balanced transparent
proxies. This can cause the same person to appear to browse from a
number of different IPs - changing perhaps even more often than Jonathan
reported.
Issac
Radoslaw Zielinski wrote:
> Jonathan Vanasco <jo...@2xlp.com> [03-08-2006 21:24]:
>> On Aug 3, 2006, at 12:31 PM, Radoslaw Zielinski wrote:
>>> Valid: exists, hasn't expired, client's IP matches (ID might have been
>>> stolen somehow), etc.
>> I find IP matching to be utterly useless. IPs for dialup/broadband
>> users change like crazy as their ISPs funnel stuff into/out of proxies.
>
>> my own ip can change every 3 minutes at times. its annoying.
>
> Uh, that's extreme. But I'd call it a broken network, not a problem
> with the idea of matching IP. With something like this, any service
> using long-lasting connections will have problems.
>
Re: Authentication
Posted by Radoslaw Zielinski <ra...@gmail.com>.
Jonathan Vanasco <jo...@2xlp.com> [03-08-2006 21:24]:
> On Aug 3, 2006, at 12:31 PM, Radoslaw Zielinski wrote:
>> Valid: exists, hasn't expired, client's IP matches (ID might have been
>> stolen somehow), etc.
> I find IP matching to be utterly useless. IPs for dialup/broadband
> users change like crazy as their ISPs funnel stuff into/out of proxies.
> my own ip can change every 3 minutes at times. its annoying.
Uh, that's extreme. But I'd call it a broken network, not a problem
with the idea of matching IP. With something like this, any service
using long-lasting connections will have problems.
--
Radosław Zieliński <ra...@pld-linux.org>
Re: Authentication
Posted by Jonathan Vanasco <jo...@2xlp.com>.
On Aug 3, 2006, at 12:31 PM, Radoslaw Zielinski wrote:
> Valid: exists, hasn't expired, client's IP matches (ID might have been
> stolen somehow), etc.
I find IP matching to be utterly useless. IPs for dialup/broadband
users change like crazy as their ISPs funnel stuff into/out of proxies.
my own ip can change every 3 minutes at times. its annoying.
Re: Authentication
Posted by Radoslaw Zielinski <ra...@pld-linux.org>.
Vladimir S. Tikhonjuk <vs...@vst.donetsk.ua> [03-08-2006 13:51]:
> The second method: simple handler, for example
> http://localhost/login, which checks login and password, If everything
> is O.K. make session, send cookie with session id. And another handler
> which checks every reqest for Cookie with session id and desided whether
> to give access or not.
> Disadvantage (as I think) of first method: before every request make
> SQL query to the database for varification login and password.
You have to do a query to check if the session is valid anyway.
Valid: exists, hasn't expired, client's IP matches (ID might have been
stolen somehow), etc.
With persistent database connections and prepared statements it doesn't
hurt that much in terms of performance. Just make sure you're not
checking what you don't have to (images, *.css, etc).
--
Radosław Zieliński <ra...@pld-linux.org>
Re: Authentication
Posted by Sean Davis <sd...@mail.nih.gov>.
On 8/3/06 7:51 AM, "Vladimir S. Tikhonjuk" <vs...@vst.donetsk.ua> wrote:
> Hi all!
>
> I'm thinking about 2 methods of authentication users for my site.
> May be you'll help me to choose one of them, or advice me something else.
>
> The first method: using PerlAuthenHandler on '/' Location.
>
> The second method: simple handler, for example
> http://localhost/login, which checks login and password, If everything
> is O.K. make session, send cookie with session id. And another handler
> which checks every reqest for Cookie with session id and desided whether
> to give access or not.
>
> Disadvantage (as I think) of first method: before every request make
> SQL query to the database for varification login and password.
You can do both. See things like:
http://search.cpan.org/~mschout/Apache-AuthCookie-3.10/lib/Apache/AuthCookie
.pm
Sean