Re: Authentication logic [was: Changing browser URL based on condition]

On 7/17/2011 1:16 AM, Phil Van wrote: Back to Vincent's original request about session id and login: how secure is your session id? Have you signed it? If not, someone can try to sending random IDs and break your authentication. Well, if you sign it and sign it properly, you basically end up wit

Re: Authentication logic [was: Changing browser URL based on condition]

Le samedi 16 juillet 2011 à 22:16 -0700, Phil Van a écrit : > Back to Vincent's original request about session id and login: > (if you are using https, then all the above procedures do not matter) > It's via https, yes. > The second idea is that you may not need to store session on the > serve

Re: Authentication logic [was: Changing browser URL based on condition]

Le samedi 16 juillet 2011 à 21:06 -0400, Perrin Harkins a écrit : > On Sat, Jul 16, 2011 at 1:01 PM, Vincent Veyron wrote: > To serialize your session to a string, you can do something like this: > use Storable qw(nfreeze); > $serialized = nfreeze \%session; > I see the light! Thanks a bunch f

Re: Authentication logic [was: Changing browser URL based on condition]

Back to Vincent's original request about session id and login: how secure is your session id? Have you signed it? If not, someone can try to sending random IDs and break your authentication. Well, if you sign it and sign it properly, you basically end up with the same idea in those "Authen + Ticke

Re: Authentication logic [was: Changing browser URL based on condition]

On Sat, Jul 16, 2011 at 1:01 PM, Vincent Veyron wrote: > As I said, I replaced the call to tie with : > > $r->pnotes('session' => Storable::retrieve($session_file)); > > where $session_file again is retrieved from the cookie. > > What I can't find out is : how do I store %session into a database >

Re: Authentication logic [was: Changing browser URL based on condition]

Le vendredi 15 juillet 2011 à 17:59 -0400, Perrin Harkins a écrit : > I think you're misunderstand. Storable doesn't do this for you. The > idea is you could capture the session in a variable and write that to > a database. > Let me explain; I used to do : tie %session, 'Apache::Session::Po

Re: Authentication logic [was: Changing browser URL based on condition]

On Thu, Jul 14, 2011 at 3:15 PM, Vincent Veyron wrote: > OK, I must have missed it in the doc, I'll look again. I think you're misunderstand. Storable doesn't do this for you. The idea is you could capture the session in a variable and write that to a database. If you'd rather not roll your ow

Re: Authentication logic [was: Changing browser URL based on condition]

Le jeudi 14 juillet 2011 à 13:02 -0400, Michael Peters a écrit : > On 07/14/2011 12:57 PM, Vincent Veyron wrote: > > Also, I did not find how to store a hash in the database without tie. I > > read it's possible to use Data::Dumper to write the data in a field and > > read it as Perl code. Would t

Re: Authentication logic [was: Changing browser URL based on condition]

On 07/14/2011 12:57 PM, Vincent Veyron wrote: This is what I first did, using Apache::Session. But I noticed the call to tie was very slow (response time around 70ms with it, 15ms without it), so I changed for Storable because filesystem reads were much faster. I don't personally like Apache::

Re: Authentication logic [was: Changing browser URL based on condition]

Le jeudi 14 juillet 2011 à 11:34 -0400, Perrin Harkins a écrit : > On Thu, Jul 14, 2011 at 11:21 AM, Vincent Veyron wrote: > > Could you explain (very briefly) how clustering prevents file storage of > > a session? > > A cluster in this case means multiple servers, so they don't share a > filesys

Re: Authentication logic [was: Changing browser URL based on condition]

On Thu, Jul 14, 2011 at 11:21 AM, Vincent Veyron wrote: > Could you explain (very briefly) how clustering prevents file storage of > a session? A cluster in this case means multiple servers, so they don't share a filesystem. There are ways to share files of course, but the common solution is to

Re: Authentication logic [was: Changing browser URL based on condition]

Le mercredi 13 juillet 2011 à 13:19 -0400, Perrin Harkins a écrit : > On Tue, Jul 12, 2011 at 8:45 AM, Vincent Veyron wrote: > > -Is there anything wrong with my process? > > If it's working for you, then it sounds fine. Needing to invoke > mod_perl on every hit could be bad if you're trying to

Re: Authentication logic [was: Changing browser URL based on condition]

On Tue, Jul 12, 2011 at 8:45 AM, Vincent Veyron wrote: > -Is there anything wrong with my process? If it's working for you, then it sounds fine. Needing to invoke mod_perl on every hit could be bad if you're trying to protect a lot of otherwise static pages, but it doesn't sound like you are. T

Re: Authentication and cookies

mod_perl list > Sent: Sun, January 23, 2011 3:09:01 PM > Subject: Re: Authentication and cookies > > Hi. > > This is a suggestion to solve what I understand of your problem, but > slightly >differently. > (And I admit that it is because I do not know if you can do

Re: Authentication and cookies

Hi. This is a suggestion to solve what I understand of your problem, but slightly differently. (And I admit that it is because I do not know if you can do that with a cookie-jar, I have never tried; but what is below, I did try and it works). The idea is as follows. A cookie is useful in the

Re: Authentication handlers in a proxy setting

> > To do access control for static files while still using your mod_perl > auth handler, take a look at mod_auth_tkt or perlbal. > Thanks!

Re: Authentication handlers in a proxy setting

On Mon, Mar 29, 2010 at 4:24 AM, Dan Axtell wrote: > server on the back end.  It seems like a lot of overhead to have mod_perl on > the front end purely for authentication; I might as well keep the monolithic > configuration I have now.  Thanks for the input, though, it helps clarify > things. It

Re: Authentication handlers in a proxy setting

On Sun, Mar 28, 2010 at 3:41 PM, Dan Axtell wrote: > What I don't understand is what to do about static directories that want to > use the handlers via Directory directive, or via a local .htdocs file.  Does > any such directory need to be forwarded to the dynamic server in order to then > call th

Re: Authentication handlers in a proxy setting

> > It would be more logical to do the authentication on the front-end > server. Then, if the back-end server needs the result of the > authentication, you could add an appropriate HTTP header (with the > user-id and maybe more stuff) to the request, before proxying it to the > back-end. > The idea

Re: Authentication handlers in a proxy setting

Dan Axtell wrote: Hi, I wrote some mod_perl handlers for authentication and authorization, basically to set cookies and check user roles. I use them for both static and dynamic content from Perl scripts. I'm looking into splitting Apache into two servers, one optimized for static content a

Re: Authentication handler

On Dec 18, 2008, at 3:31 PM, André Warnier wrote: Bruce Johnson wrote: I'm looking at the code at the modperl.com site ('Authenticating against a database') as I need to write an authentication handler for our site. This is part of the sample

Re: Authentication handler

Bruce Johnson wrote: I'm looking at the code at the modperl.com site ('Authenticating against a database') as I need to write an authentication handler for our site. This is part of the sample code: # file: Apache/GateKeeper.pm use strict; use A

Re: Authentication Problem

Scott Gifford <[EMAIL PROTECTED]> writes: [...] > The cause seems to be that when mod_perl gets an "Authorization" > header in the request, it doesn't supply a "WWW-Authenticate" header > in the response. Nevermind, found it, the solution was to call: $r->note_basic_auth_failure(); Sco

Re: Authentication

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 busine

Re: Authentication

Jonathan Vanasco <[EMAIL PROTECTED]> [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

Re: Authentication

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

Re: Authentication

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

Re: Authentication

Jonathan Vanasco <[EMAIL PROTECTED]> [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

Re: Authentication

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

Re: Authentication

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 Lo

Re: Authentication

Vladimir S. Tikhonjuk <[EMAIL PROTECTED]> [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

Re: Authentication

On 8/3/06 7:51 AM, "Vladimir S. Tikhonjuk" <[EMAIL PROTECTED]> 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 '/' Locati

Re: Authentication

Martin Moss wrote on 11/10/05, 1:25 PM: > Although saying that I was trying to do a set_handlers > for the contentphase... which was being completely > ignored by apache... Marty, Not sure it's related, but I had what sounds like a similar problem with an authorization handler. I wanted to r

Re: Authentication

Hi Marty, I must be missing something here... If I understand, you're timing out a login but if it does time out, you're automatically re-authenticating without user interaction? Why not just take away the login timeout or make it longer? John Martin Moss wrote: I'll have a think about i

Re: Authentication

You wouldn't believe the problems I've had with AccessHandlers... Although saying that I was trying to do a set_handlers for the contentphase... which was being completely ignored by apache... I'll have a think about it... But the idea is to make the authentication be completely invisible to the

Re: Authentication

My fault guys, not looking up the numbers - Martin is your admin complaining about too many FORBIDDENs or REDIRECTs? The only thing I can add is that I'd recommend not using the authentication pages/handler to redirect - make yourself an Access phase (eg. "if no valid cookie, redirect to HTTPS

Re: Authentication

On Thu, 2005-11-10 at 17:19 +, Martin Moss wrote: > So an Authen Handler can return a REDIRECT? > > I use a 403 custom repsonse which is a self submitting > page (with non javascript handling)... By doing so it > prevent's any of the authentication pages appearing in > IE's back button on the

Re: Authentication

So an Authen Handler can return a REDIRECT? I use a 403 custom repsonse which is a self submitting page (with non javascript handling)... By doing so it prevent's any of the authentication pages appearing in IE's back button on the browser... Marty --- Perrin Harkins <[EMAIL PROTECTED]> wrot

Re: Authentication

On Thu, 2005-11-10 at 16:20 +, John ORourke wrote: > You can avoid some redirection by having a non-HTTPS form which submits > to the HTTPS login page (although users might worry, no padlock icon). > Otherwise it's perfectly reasonable to redirect to a secure login. On > successful login s

Re: Authentication

Martin, You can avoid some redirection by having a non-HTTPS form which submits to the HTTPS login page (although users might worry, no padlock icon). Otherwise it's perfectly reasonable to redirect to a secure login. On successful login simple 403 the user back to the page they wanted. Th

Re: Authentication problem

Hi, what's your MaxClients setting in your apache conf? It could just be that you aren't running enough apache child processes to serve the number of connections being made, Regards Marty --- "Levi E. Stanley" <[EMAIL PROTECTED]> wrote: > Hi, > > Been seeing problems with an Authenticate scr

Re: Authentication using https

while you're at it you might take a look at the kerberos-like AIS infrastructure, which does not at this time use apache extensions at all but which provides passwordless e-mail-based SSO over an arbitrarily wide domain. -- David L Nicol "It's what God and Dwight Eisenhower intended, and it's w

Re: Authentication using https

Cheers Fellas, this was the bit I was concerned about. Apache::AuthCookie, looked a little bloated to me, however I'm a big fan of only inventying new types of wheels not old so I'll revisit... Regards Marty --- Michael J Schout <[EMAIL PROTECTED]> wrote: > On Wed, 10 Nov 2004, Skylos wrote:

Re: Authentication using https

On Wed, 10 Nov 2004, Skylos wrote: it could go... -> GET content from myserver port 80 <- 403 errordocument login form -> POST credentials to myserver port 443 <- Location http://myserver/content <- Set-Cookie: ticket=gooduser; Domain=myserver; Path=content; -> GET content from myserver port 80 <-

Re: Authentication using https

Michael, I'm sorry but I don't believe that is correct. Having recently implimented a Apache::AuthCookie system, I can see a possible issue with this strategy. Please feel free to enlighten me if I am full of shit. First of all, there's nothing stopping you from submitting your login form to an

Re: Authentication using https

Michael wrote on 11/10/04, 4:28 PM: > > All, > > > > I'm about to replace the authentication mechanism that > > our web site uses. However I wanted to sanity check my > > thought process. > > > > Is it possible to have an Authen handler sitting on > > certain areas of a site, and if a us

Re: Authentication using https

> All, > > I'm about to replace the authentication mechanism that > our web site uses. However I wanted to sanity check my > thought process. > > Is it possible to have an Authen handler sitting on > certain areas of a site, and if a user isn't logged in > (i.e. doesn't have an auth session cook

RE: authentication with smb

> 1. Updated Authen::Smb with this: > > use Fcntl qw(:flock); > ... > open S, "> /full/path/to/AuthenSmb.lck" or > die "Can't open AuthenSmb.lck: $!\n"; > flock S, LOCK_EX; > my $res = Valid_User($username, $password, $server, $backup, $domain); > close S; I was given this solution, to fix the pr

Re: authentication with smb

Stas Bekman wrote: yo! please trim the quoted text in your replies to the mimimal relevant size. those who need to read the whole thing have the archives. thanks. Will do. speeves cws -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html

Re: authentication with smb

yo! please trim the quoted text in your replies to the mimimal relevant size. those who need to read the whole thing have the archives. thanks. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/

Re: authentication with smb

cramirez wrote: Awhile back, I encountered this same problem and found a solution from Matt Arnold's mod_perl post, which I cannot locate at the time. Anyhow, here's the fix that I've been using in our production environment. 1. Update Authen::Smb like so: use Fcntl qw(:flock); ... open S,

RE: authentication with smb

Thanks for the 'patches' to the modules! > 1. Update Authen::Smb like so: > > use Fcntl qw(:flock); > ... > open S, "> /full/path/to/AuthenSmb.lck" or > die "Can't open AuthenSmb.lck: $!\n"; > flock S, LOCK_EX; > my $res = Valid_User($username, $password, $server, $backup, $domain); > close S; W

Re: authentication with smb

Awhile back, I encountered this same problem and found a solution from Matt Arnold's mod_perl post, which I cannot locate at the time. Anyhow, here's the fix that I've been using in our production environment. 1. Update Authen::Smb like so: use Fcntl qw(:flock); ... open S, "> /full/path/to/A

Re: authentication with smb

Tauber, Mathias HDP wrote: hi, I have just subscribed to this mailing list, so I hope I'm doing everything right... my problem: I'm running a reverse proxy with apache 1.3.x and mod_proxy on debian. For the authentication libapache-authensmb is used, so there's a connection to the domain control