From: Magnus L. H. <ma...@he...> - 2002-02-27 00:50:15
|
I've been trying to translate som HTTP authentication code I've got lying around for PHP into Python (using WebKit). I've figured out that I can get the authentication started by supplying a WWW-Authenticate header and setting the status to 401, but my question is -- where can I find the username and password? PHP uses PHP_AUTH_USER and PHP_AUTH_PASS... -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
From: Ian B. <ia...@co...> - 2002-02-27 01:05:24
|
There's some discussion in Zope about this... if you look at information about using Zope on a commercial host it'll discuss this, but I think the standard installation notes also discuss it. If Apache has the authorization information then you can get it from an environment variable (HTTP_USER or something). Otherwise you have to do configure something in Apache to allow CGI scripts to do authentication. I've never liked HTTP authentication, so besides Zope I've never considered using it. It's mostly the fault of the browsers, though. On Tue, 2002-02-26 at 18:50, Magnus Lie Hetland wrote: > I've been trying to translate som HTTP authentication code I've got > lying around for PHP into Python (using WebKit). I've figured out that > I can get the authentication started by supplying a WWW-Authenticate > header and setting the status to 401, but my question is -- where can > I find the username and password? PHP uses PHP_AUTH_USER and > PHP_AUTH_PASS... > > -- > Magnus Lie Hetland The Anygui Project > http://hetland.org http://anygui.org > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: <ir...@ms...> - 2002-02-27 02:13:01
|
On Tue, Feb 26, 2002 at 07:09:46PM -0600, Ian Bicking wrote: > There's some discussion in Zope about this... if you look at information > about using Zope on a commercial host it'll discuss this, but I think > the standard installation notes also discuss it. > > If Apache has the authorization information then you can get it from an > environment variable (HTTP_USER or something). Otherwise you have to do > configure something in Apache to allow CGI scripts to do authentication. RewriteCond %{HTTP:Authorization} ^(.*) RewriteRule ^/(.*) /usr/lib/cgi-bin/Zope.cgi/M/$1 [e=HTTP_CGI_AUTHORIZATION:%1, t=application/x-httpd-cgi,l] (The second and third lines are really one long line.) -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Magnus L. H. <ma...@he...> - 2002-02-27 16:10:16
|
Mike Orr <ir...@se...>: > [...] > RewriteCond %{HTTP:Authorization} ^(.*) > RewriteRule ^/(.*) /usr/lib/cgi-bin/Zope.cgi/M/$1 \ > [e=HTTP_CGI_AUTHORIZATION:%1, t=application/x-httpd-cgi,l] Thanks. I've found several versions of this on the web and I think I understand the way it ought to function -- but I can't make it work. Even if I supply a literal value for HTTP_CGI_AUTHORIZATION, I can't find it with req.hasField afterwards... I basically have code like this: if not req.hasField('HTTP_CGI_AUTHORIZATION'): res.addHeader('WWW-Authenticate', 'Basic realm=Something') res.setStatus(401) self.write('Authorisation required') return else: # Get HTTP_CGI_AUTHORIZATION and perform a login check etc. However, it only seems to enter the first clause, repeatedly asking me for a usernam/password. I would have thought that after having provided that, the field HTTP_CGI_AUTHORIZATION should be set, thus avoiding the authentication headers etc... Is there something wrong with this code? (It would obviously seem so...) And, BTW -- what form does the HTTP_CGI_AUTHORIZATION header have? Username/password separated somehow? -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
From: <ir...@ms...> - 2002-02-27 17:55:20
|
On Wed, Feb 27, 2002 at 05:10:07PM +0100, Magnus Lie Hetland wrote: > Mike Orr <ir...@se...>: > > > [...] > > RewriteCond %{HTTP:Authorization} ^(.*) > > RewriteRule ^/(.*) /usr/lib/cgi-bin/Zope.cgi/M/$1 \ > > [e=HTTP_CGI_AUTHORIZATION:%1, t=application/x-httpd-cgi,l] > > Thanks. I've found several versions of this on the web and I think I > understand the way it ought to function -- but I can't make it work. > Even if I supply a literal value for HTTP_CGI_AUTHORIZATION, I can't > find it with req.hasField afterwards... The rules above are copied straight from my old Zope install. I haven't tried them with Webware. > What do you see as the problem with HTTP authentication? I think it > simplifies my code quite a lot, since I don't have to think about > sessions and login pages and the like... Basic authentication is great if you can live with its limitations. I haven't used it with Webware, but on other platforms it's always been easy to set up and reliable. Under Apache you can use a standard htpasswd file for static users, or mod_auth_mysql if your application itself creates users. With mod_auth_mysql, all your application has to do is maintain username and password columns (under any column names) in the table you store your other user info in, and voila`, Apache takes care of the rest. In PHP, the servlet then reads the envvar $HTTP_SERVER_VARS['PHP_AUTH_USER'] to determine the current user. You don't care about the password because they've already been authenticated. My memory is failing as to where PHP_AUTH_USER comes from; whether PHP extracts it from HTTP_CGI_AUTHORIZATION or whether Apache supplies an AUTH_USER envvar, but you can find it in Webware by looking at all the envvars in the traceback. The database password can be in plaintext or one of several encryption schemes, but you have to encrypt the password yourself when you store it. mod_auth_mysql can cascade through several encryption schemes while it tries to match the password, if you decide to change encryption schemes but already have existing users. Some disadvantages of Basic Authentication: ** You can't customize the login dialog except the short "realm name" string. If users are confused about why they are being asked for a password, there's no way to provide a "click here for help" hyperlink. ** Users can't log out without quitting the browser. There's no way to provide a "logout" button because the browsers don't provide that feature. If a user goes to lunch and leaves their browser open, a creep can sit at their desk and have all their privileges. ** Users can't relog in as someone else without quitting the browser. This may be necessary for some applications. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Magnus L. H. <ma...@he...> - 2002-02-27 20:31:31
|
Mike Orr <ir...@se...>: [...] > The rules above are copied straight from my old Zope install. I haven't > tried them with Webware. Well, they seem correct. The odd thing is that I can't seem to set the environmentvariable through the E rewrite directive. [...] > Basic authentication is great if you can live with its limitations. > I haven't used it with Webware, but on other platforms it's always been > easy to set up and reliable. Under Apache you can use a standard > htpasswd file for static users, or mod_auth_mysql if your > application itself creates users. Interesting. I'm using postgres, but I see there's a mod_auth_pgsql as well. [...] > My memory is failing as to where PHP_AUTH_USER > comes from; I guess that's where my problem is; initiating the authentication process is easy enough; I just can't get the username and password afterwards... > whether PHP extracts it from HTTP_CGI_AUTHORIZATION or Is that a standard environment variable? When I searched for it, I only found lots of versions of the Zope recipe. > whether Apache supplies an AUTH_USER envvar, but you can find it in > Webware by looking at all the envvars in the traceback. I tried, but since my authentication didn't work, no such environment variable was present. I guess I'll just try with a .htpasswd file or something (which should set the environment variables properly, I guess.) [...] > Some disadvantages of Basic Authentication: > > ** You can't customize the login dialog except the short "realm name" > string. If users are confused about why they are being asked for a > password, there's no way to provide a "click here for help" hyperlink. True. I can live with that -- especially if you have an intro screen with a help link etc, and a "log in" button/link or something. > ** Users can't log out without quitting the browser. There's no way > to provide a "logout" button because the browsers don't provide that > feature. I've heard that said before... Wouldn't it be a simple matter of providing the "unauthorized"/401 header/status again, and then have the user clicking cancel? [...] > ** Users can't relog in as someone else without quitting the browser. Ditto? [...] -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
From: Magnus L. H. <ma...@he...> - 2002-02-27 20:49:50
|
Magnus Lie Hetland <ma...@he...>: > > Mike Orr <ir...@se...>: > > My memory is failing as to where PHP_AUTH_USER > > comes from; > > I guess that's where my problem is; initiating the authentication > process is easy enough; I just can't get the username and password > afterwards... It seems (as I think I remember from several years ago) that REMOTE_USER is the thing. When I thumb through the Webware manual, I see there is even a separate method for this in the HTTPRequest class: remoteUser(). (I assume this is the same as field('REMOTE_USER').) But there is no such standard for the password, IIRC. (I even remember a patch somewhere a long time ago, fixing this for Apache. I would assume the situation is different today.) But I can't seem to get the REMOTE_USER set either. Odd -- I would have thought that basic HTTP authentication was a fairly standard thing to do... -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
From: <ir...@ms...> - 2002-02-27 21:27:00
|
On Wed, Feb 27, 2002 at 09:49:32PM +0100, Magnus Lie Hetland wrote: > > I guess that's where my problem is; initiating the authentication > > process is easy enough; I just can't get the username and password > > afterwards... > > It seems (as I think I remember from several years ago) that > REMOTE_USER is the thing. That sounds familiar too... In any case, when we figure it out we need to put it on the wiki as an alternate authentication method. > But there is no such standard for the password, IIRC. If you need the password, van you use database authentication and look up the password in the database by the username? -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Magnus L. H. <ma...@he...> - 2002-02-27 21:47:23
|
Mike Orr <ir...@se...>: [...] > That sounds familiar too... > > In any case, when we figure it out we need to put it on the wiki as an > alternate authentication method. Yeah. I would even go so far as to suggest perhaps a utility method or two... No real need to go through all this explicit header-passing and environment variable-parsing if you could just have a method that dealt with it... E.g. instead of having req.remoteUser() raise an exception if the user isn't log in, how about asking the user for a username and password? (This may not be the most appropriate place to put the code -- I don't know.) > > But there is no such standard for the password, IIRC. > > If you need the password, van you use database authentication and look up the > password in the database by the username? If I have a database authentication solution, I will no longer need the password. The problem is that I'm currently using a plain vanilla binary rpm installation of Apache, and would rather not mess around with compiling and installing modules unless I really have to. If I could solve this all in Webware, that would be preferrable. (Otherwise, mod_auth_pgsql sounds like a very good alternative.) Anyhow: Whether it be based on HTTP authentication, or a standard cgi/form/session solution, it seems to me that a fully encapsulated and extremely simple authentication mechanism would be useful in Webware. The example from the distribution is nice enough (and I've recoded it into a custom version), but not exactly dead simple; if I were a newbie trying to set up a password-protected PSP page, I would probably give up very quickly. -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
From: Ian B. <ia...@co...> - 2002-02-28 00:39:51
|
On Wed, Feb 27, 2002 at 10:47:15PM +0100, Magnus Lie Hetland wrote: > Mike Orr <ir...@se...>: > [...] > > That sounds familiar too... > > > > In any case, when we figure it out we need to put it on the wiki as an > > alternate authentication method. > > Yeah. I would even go so far as to suggest perhaps a utility method or > two... No real need to go through all this explicit header-passing and > environment variable-parsing if you could just have a method that > dealt with it... E.g. instead of having req.remoteUser() raise an > exception if the user isn't log in, how about asking the user for a > username and password? (This may not be the most appropriate place to > put the code -- I don't know.) > > > > But there is no such standard for the password, IIRC. > > > > If you need the password, van you use database authentication and look up the > > password in the database by the username? > > If I have a database authentication solution, I will no longer need > the password. The problem is that I'm currently using a plain vanilla > binary rpm installation of Apache, and would rather not mess around > with compiling and installing modules unless I really have to. If I > could solve this all in Webware, that would be preferrable. > (Otherwise, mod_auth_pgsql sounds like a very good alternative.) Debian has packages for all the major auth modules -- even a lesser distribution like RedHat probably has the same ;) So it's pretty easy. > Anyhow: Whether it be based on HTTP authentication, or a standard > cgi/form/session solution, it seems to me that a fully encapsulated > and extremely simple authentication mechanism would be useful in > Webware. The example from the distribution is nice enough (and I've > recoded it into a custom version), but not exactly dead simple; if I > were a newbie trying to set up a password-protected PSP page, I would > probably give up very quickly. I have a decent solution for the way I make my pages -- but what I'd *like* to be able to do in a page is throw an exception that would cause a login page (and the same for a redirect). Doing this with the current system (dictated by Page and somewhat by Servlet) is difficult and crude. I use a special method I coded into HTTPResponse that catches all the .write()s and I wrap both the awake()s and writeContent()s in try's, and I set a instance variable if something happens... but it's crude and has had a number of subtle bugs. Having awake() and writeContent() seperate makes it difficult -- I kind of like the pattern of using awake() for actions, but I sometimes wish I didn't do it that way and just put everything in writeContent(). -- Ian Bicking Colorstudy Web Design ia...@co... http://www.colorstudy.com 4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241 |
From: Magnus L. H. <ma...@he...> - 2002-03-01 00:46:20
|
Ian Bicking <ia...@co...>: [...] > > (Otherwise, mod_auth_pgsql sounds like a very good alternative.) > > Debian has packages for all the major auth modules -- even a lesser > distribution like RedHat <cough, cough> > probably has the same ;) So it's pretty easy. Yeah, I found an RPM (for the "lesser" RedHat package manager ;) But now I'm just trying to turn on basic authentication via Apache (without using WebKit for the task), but that seems tricky, since as far as I can tell, that can only be done in a .htaccess file or a Directory directive, both of which seem to be ignored when using WebKit, since I'm not accessing the files "through Apache" anymore. (Of course, I can add protection to the WebKit cgi script itself, but that would be excessive, as would it be to add a separate cgi script for the protected directory/ies.) Isn't there a way to make Apache trigger its authentication *before* rewriting and forwarding the request (i.e. adding a Require directive to a URL, rather than an absolute path)? -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
From: <ir...@ms...> - 2002-03-01 02:20:37
|
On Fri, Mar 01, 2002 at 01:46:09AM +0100, Magnus Lie Hetland wrote: > Ian Bicking <ia...@co...>: > [...] > > > (Otherwise, mod_auth_pgsql sounds like a very good alternative.) > > > > Debian has packages for all the major auth modules -- even a lesser > > distribution like RedHat > > <cough, cough> > > > probably has the same ;) So it's pretty easy. > > Yeah, I found an RPM (for the "lesser" RedHat package manager ;) > > But now I'm just trying to turn on basic authentication via Apache > (without using WebKit for the task), but that seems tricky, since as > far as I can tell, that can only be done in a .htaccess file or a > Directory directive, both of which seem to be ignored when using > WebKit, since I'm not accessing the files "through Apache" anymore. > (Of course, I can add protection to the WebKit cgi script itself, but > that would be excessive, as would it be to add a separate cgi script > for the protected directory/ies.) > > Isn't there a way to make Apache trigger its authentication *before* > rewriting and forwarding the request (i.e. adding a Require directive > to a URL, rather than an absolute path)? Try <Location> instead of <Directory>. <Location> works by URL rather than directory. I know Allow/Deny + mod_rewrite + mod+webkit all inside a <Location> work, so there must be a way to get basic authentication to work too. If you can post or send me the portion of your httpd.conf that does the webkit and the rewrites, or the entire virtual host, perhaps we can figure something out. I think you can also change the order of the LoadModule and/or AddModule directives to control which order they are applied to the request. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: <ir...@ms...> - 2002-02-27 21:33:15
|
On Wed, Feb 27, 2002 at 09:31:21PM +0100, Magnus Lie Hetland wrote: > I guess I'll just try with a .htpasswd file or > something (which should set the environment variables properly, I > guess.) That's probably the best way to test it. But on a production server, putting the auth config in a <Location> directive in the webserver config file rather than an .htaccess file provides slightly better security. You can also turn off .htaccess parsing for a slight increase in speed. > > ** Users can't log out without quitting the browser. There's no way > > to provide a "logout" button because the browsers don't provide that > > feature. > > I've heard that said before... Wouldn't it be a simple matter of > providing the "unauthorized"/401 header/status again, and then have > the user clicking cancel? > > [...] > > ** Users can't relog in as someone else without quitting the browser. > > Ditto? A simple matter of who doing what? It'd be a simple matter for the browser to have an option that displays a list of servers/realms/usernames and lets you selectively delete them. That would make the browser forget the password and then you'd get the authentication dialog again. But AFAIK no browser does this, and you may not have the source code to the browser, or feel like modifying C code. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Magnus L. H. <ma...@he...> - 2002-02-27 21:41:32
|
Mike Orr <ir...@se...>: > > On Wed, Feb 27, 2002 at 09:31:21PM +0100, Magnus Lie Hetland wrote: > > I guess I'll just try with a .htpasswd file or > > something (which should set the environment variables properly, I > > guess.) > > That's probably the best way to test it. But on a production server, > putting the auth config in a <Location> directive in the webserver > config file rather than an .htaccess file provides slightly better > security. You can also turn off .htaccess parsing for a slight > increase in speed. It seems I'll have to do something like that anyway... Since the test document is served through WebKit (and not directly through Apache) the .htaccess file seems to be ignored. [...] > A simple matter of who doing what? Sending the same headers as when asking for the password to begin with. > It'd be a simple matter for the > browser to have an option that displays a list of servers/realms/usernames > and lets you selectively delete them. Yes. I was talking about a server-side solution for todays situation. > That would make the browser > forget the password and then you'd get the authentication dialog again. > But AFAIK no browser does this, and you may not have the source code to > the browser, or feel like modifying C code. Sure. My point was that you probably can (although I haven't tested it) simply send an "unauthorized" header to the browser and have the user press cancel to make it forget the password. Not ideal, sure; but at least (if this really works ;) it isn't impossible to log out, or to re-login. -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
From: Ian B. <ia...@co...> - 2002-02-28 00:28:05
|
On Wed, Feb 27, 2002 at 09:31:21PM +0100, Magnus Lie Hetland wrote: > Mike Orr <ir...@se...>: > [...] > > The rules above are copied straight from my old Zope install. I haven't > > tried them with Webware. > > Well, they seem correct. The odd thing is that I can't seem to set the > environmentvariable through the E rewrite directive. I'm pretty sure there's more to it than the rewrite rule. There's a security issue. To explain, if user A (at http://whatever.com/~A) has authentication, and then the browser user goes to B's site (http://whatever.com/~B) and they get a 401, they'll pass their cached username and password. This is fine if Apache does the checking, but if you pass the password directly to the script then you've introduced a significant security hole, because B was given the password. mod_rewrite rules can be in your .htaccess, so it's a problem. If you read closer into the Zope docs, I feel like there was a specific configuration setting you had to change to get the rewrite rules to work. > > Some disadvantages of Basic Authentication: > > > > ** You can't customize the login dialog except the short "realm name" > > string. If users are confused about why they are being asked for a > > password, there's no way to provide a "click here for help" hyperlink. > > True. I can live with that -- especially if you have an intro screen > with a help link etc, and a "log in" button/link or something. True. I think you can also send a 401 and a page, so if they cancel they'll get the page you sent -- which can have links about forgotten passwords and all that. TWiki does this, I think. > > ** Users can't log out without quitting the browser. There's no way > > to provide a "logout" button because the browsers don't provide that > > feature. > > I've heard that said before... Wouldn't it be a simple matter of > providing the "unauthorized"/401 header/status again, and then have > the user clicking cancel? I think you'd have to test it out, as I'm not sure this is the case. A smart script could send a 401, get the username/password, and then send the 401 a second time... that might not work either -- though it would allow someone to log in as a different username. Otherwise if you have access to the password, maybe you could force them to login with a blank password (or even just any incorrect password) as an alternative for a true logout. Ian |
From: Magnus L. H. <ma...@he...> - 2002-02-27 15:37:53
|
Ian Bicking <ia...@co...>: > > There's some discussion in Zope about this... if you look at information > about using Zope on a commercial host it'll discuss this, but I think > the standard installation notes also discuss it. > > If Apache has the authorization information then you can get it from an > environment variable (HTTP_USER or something). Yes, that sounds familiar. (I can't get HTTP_USER to work, though... I guess perhaps I'll have to coax Apache a bit.) > Otherwise you have to do > configure something in Apache to allow CGI scripts to do authentication. > > I've never liked HTTP authentication, so besides Zope I've never > considered using it. It's mostly the fault of the browsers, though. What do you see as the problem with HTTP authentication? I think it simplifies my code quite a lot, since I don't have to think about sessions and login pages and the like... -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
From: Tavis R. <ta...@re...> - 2002-02-27 21:01:04
|
Why not just use some form of webware-based authentication? You'll get better control, support, and possibly security (assuming https). On Wednesday 27 February 2002 12:49, Magnus Lie Hetland wrote: > Magnus Lie Hetland <ma...@he...>: > > Mike Orr <ir...@se...>: > > > My memory is failing as to where PHP_AUTH_USER > > > comes from; > > > > I guess that's where my problem is; initiating the authentication > > process is easy enough; I just can't get the username and > > password afterwards... > > It seems (as I think I remember from several years ago) that > REMOTE_USER is the thing. When I thumb through the Webware manual, > I see there is even a separate method for this in the HTTPRequest > class: remoteUser(). (I assume this is the same as > field('REMOTE_USER').) > > But there is no such standard for the password, IIRC. (I even > remember a patch somewhere a long time ago, fixing this for Apache. > I would assume the situation is different today.) > > But I can't seem to get the REMOTE_USER set either. Odd -- I would > have thought that basic HTTP authentication was a fairly standard > thing to do... |
From: Magnus L. H. <ma...@he...> - 2002-02-27 21:11:49
|
Tavis Rudd <ta...@re...>: > > Why not just use some form of webware-based authentication? You'll > get better control, support, and possibly security (assuming https). That's an alternative, yes. In fact, I already have that implemented. I would just like to see how simple it would be to use HTTP authentication (which I found to be very convenient when working with PHP). -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
From: <ir...@ms...> - 2002-02-27 21:23:30
|
On Wed, Feb 27, 2002 at 02:14:56PM -0800, Tavis Rudd wrote: > Why not just use some form of webware-based authentication? You'll > get better control, support, and possibly security (assuming https). It's a question of using the simplest technology necessary to do the job, preferring something that's long established and very widely tested if it's adequate. And of course, "adequate" depends on the particular application. Some applications may require the features a Python authentication module can provide; for others it's overkill, and all the little quirks that come up just mean more things to debug. And of course, some sites may prefer to standardize on one authentication module for everything because it's required for one of their applications. But they should have the choice of using different existing modules according to the type of application, if they wish. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Tavis R. <ta...@re...> - 2002-02-27 21:26:25
|
Good point. However, with Apache there should be a way around that. Install mod_python, write your authentication code so it can work independent of Webware and then install it as an Apache module via mod_python. Of course, that's not exactly simple, unless someone has already done it for you. On Wednesday 27 February 2002 13:11, Aaron Held wrote: > I can see the situation where you want a unified login to both > apache and webware resources. You may run into a situation like > the IBM developerworks tutorial login, you have to login to a web > form and then you still have login via basic http > > The usernames are synced, but you still have to login twice. > > -Aaron > ----- Original Message ----- > From: "Tavis Rudd" <ta...@re...> > To: "Magnus Lie Hetland" <ma...@he...>; > <web...@li...> > Sent: Wednesday, February 27, 2002 5:14 PM > Subject: Re: [Webware-discuss] HTTP authentication > > > Why not just use some form of webware-based authentication? > > You'll > > > get better control, support, and possibly security (assuming > > https). > > > On Wednesday 27 February 2002 12:49, Magnus Lie Hetland wrote: > > > Magnus Lie Hetland <ma...@he...>: > > > > Mike Orr <ir...@se...>: > > > > > My memory is failing as to where PHP_AUTH_USER > > > > > comes from; > > > > > > > > I guess that's where my problem is; initiating the > > authentication > > > > > process is easy enough; I just can't get the username and > > > > password afterwards... > > > > > > It seems (as I think I remember from several years ago) that > > > REMOTE_USER is the thing. When I thumb through the Webware > > manual, > > > > I see there is even a separate method for this in the > > HTTPRequest > > > > class: remoteUser(). (I assume this is the same as > > > field('REMOTE_USER').) > > > > > > But there is no such standard for the password, IIRC. (I even > > > remember a patch somewhere a long time ago, fixing this for > > Apache. > > > > I would assume the situation is different today.) > > > > > > But I can't seem to get the REMOTE_USER set either. Odd -- I > > would > > > > have thought that basic HTTP authentication was a fairly > > standard > > > > thing to do... > > > > _______________________________________________ > > Webware-discuss mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Tavis R. <ta...@re...> - 2002-02-27 21:57:15
|
On Wednesday 27 February 2002 13:47, Magnus Lie Hetland wrote: > > > But there is no such standard for the password, IIRC. > > > > If you need the password, van you use database authentication and > > look up the password in the database by the username? > > If I have a database authentication solution, I will no longer need > the password. The problem is that I'm currently using a plain > vanilla binary rpm installation of Apache, and would rather not > mess around with compiling and installing modules unless I really > have to. If I could solve this all in Webware, that would be > preferrable. (Otherwise, mod_auth_pgsql sounds like a very good > alternative.) > > Anyhow: Whether it be based on HTTP authentication, or a standard > cgi/form/session solution, it seems to me that a fully encapsulated > and extremely simple authentication mechanism would be useful in > Webware. The example from the distribution is nice enough (and I've > recoded it into a custom version), but not exactly dead simple; if > I were a newbie trying to set up a password-protected PSP page, I > would probably give up very quickly. I agree!! We talked about this back in Nov and put some notes on the Wiki, but people got busy and the thread died out. Here's the relevant URLs: http://webware.colorstudy.net/twiki/bin/view/Webware/UserHandlingProj http://webware.colorstudy.net/twiki/bin/view/Webware/WebwareUserManager Ng's authcookie extension to m2crypto sounds perfect for this sort of stuff, but I have tested it yet. Cheers Tavis |
From: Magnus L. H. <ma...@he...> - 2002-02-27 22:07:50
|
Tavis Rudd <ta...@re...>: [snip] > > Anyhow: Whether it be based on HTTP authentication, or a standard > > cgi/form/session solution, it seems to me that a fully encapsulated > > and extremely simple authentication mechanism would be useful in > > Webware. The example from the distribution is nice enough (and I've > > recoded it into a custom version), but not exactly dead simple; if > > I were a newbie trying to set up a password-protected PSP page, I > > would probably give up very quickly. > > I agree!! We talked about this back in Nov and put some notes on the > Wiki, but people got busy and the thread died out. > Here's the relevant URLs: > http://webware.colorstudy.net/twiki/bin/view/Webware/UserHandlingProj > http://webware.colorstudy.net/twiki/bin/view/Webware/WebwareUserManager This looks great -- but perhaps a bit ambitious? I'm not saying the project should be scaled down, but that perhaps a more modest mechanism could be added as an initial step? (It might have a better chance of actually being implemented... :) Perhaps simply wrapping up the code from the example in the distribution in such a way that one could use/inherit it without knowing how it works? (To make this simple enough, one would perhaps have to drop the ID field stuff...) My hope was that HTTP auth could give me a ready-made, simple solution, when Webware didn't have one built-in... Even though I have one solution implemented, I generally like better to rely on standard solutions (maintained as part of the distribution) than to implement my own, when there is no obvious reason for me to do so. > Ng's authcookie extension to m2crypto sounds perfect for this sort of > stuff, but I have tested it yet. Sounds nice... (I guess this would require a separate installation of m2crypto...?) > Cheers > Tavis -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org |
From: Tavis R. <ta...@re...> - 2002-02-27 22:52:48
|
On Wednesday 27 February 2002 14:07, Magnus Lie Hetland wrote: > This looks great -- but perhaps a bit ambitious? I'm not saying the > project should be scaled down, but that perhaps a more modest > mechanism could be added as an initial step? (It might have a > better chance of actually being implemented... :) Oh, it was very ambitious - partially because some of the issues can be rather complex when you start talking about integrated authentication with stuff happening outside of Webware like Aaron did today. And how about providing authenticated access to static files that WebKit is serving up? You can't easily use inheritance to do that, unless you start modifying the servlet factories. Coding up a custom solution isn't that hard, but things get much more complicated when we talk about something that is worthy of inclusion in the standard distribution. The last thing we want to do is encourage people to blindly trust a built-in authentication mechanism that may or may not be secure. Anyway, I agree that the best way to get this thing rolling is to do what you and Geoff are suggesting and work up from SecurePage and LoginPage. However, I'd suggested putting them in a separate 'kit', rather than directly in WebKit. 'AuthKit' or even as part of 'UserKit'? Or how about some simple modules attached to the Wiki pages at this stage? > Perhaps simply wrapping up the code from the example in the > distribution in such a way that one could use/inherit it without > knowing how it works? (To make this simple enough, one would > perhaps have to drop the ID field stuff...) See my comment above. Blind faith is dangerous. > My hope was that HTTP auth could give me a ready-made, simple > solution, when Webware didn't have one built-in... Even though I > have one solution implemented, I generally like better to rely on > standard solutions (maintained as part of the distribution) than to > implement my own, when there is no obvious reason for me to do so. Ditto. > > Ng's authcookie extension to m2crypto sounds perfect for this > > sort of stuff, but I have tested it yet. > > Sounds nice... (I guess this would require a separate installation > of m2crypto...?) Yep. Cheers Tavis |