From: Ian B. <ia...@co...> - 2002-05-10 22:07:52
|
Okay, I got HTTP authentication working (thanks Bill). I couldn't get the Zope method to work quite right, as environmental variables weren't passed on. Anyway, a page describing it is at: http://webware.colorstudy.net/twiki/bin/view/Webware/HttpAuthentication Ian |
From: Stuart D. <st...@as...> - 2003-03-30 04:17:29
|
Howdy. Has anyone dones any HTTP Authentication for Webware? To allow a webware applet to use the HTTP authentication mechanism? There are some bare references in WebKit/Experimental like someone started down this path, but it isn't clear where they were going. -Stuart- p.s. Sorry I haven't been around much lately, I have been swamped mostly at work right now, and I just haven't had much opportunity to even keep up with the e-mail in the discussion threads. Hopefully I will be back to participating here more regularly within a month or so. |
From: Ian B. <ia...@co...> - 2003-03-30 06:07:14
|
On Sat, 2003-03-29 at 22:17, Stuart Donaldson wrote: > Has anyone dones any HTTP Authentication for Webware? To allow a > webware applet to use the HTTP authentication mechanism? Yes, I've done this before. The complexity is mostly in getting Apache to actually send the password -- without significant configuration, Apache hides all passwords. Zope has the same issue, and documentation for that should translate. Also, using the built-in HTTP server you'll have no problems (you'll get an HTTP_AUTHENTICATION environmental variable, I believe, and use base64 to decode the value). Annoyingly, most of the support needs to be done outside of Webware. Ian |
From: Bill E. <bi...@rf...> - 2002-05-11 13:11:34
|
Is there a way to get APache to use WK for authentication even for non-WK pages using something like this? It looks like someone's been working on something similar here: http://mod-auth-script.sourceforge.net/ And another at: http://www.unixpapa.com/mod_auth_external.html As well as other Apache modules: http://modules.apache.org/search (search for auth). Note that Mozilla now supports Digest Authentication. http://www.mozilla.org/projects/netlib/http/ http://www.mozilla.org/releases/mozilla0.9.7/#new Digest Apache module here: http://www.berlinonline.de/wissen/computer/linux_tips/os/ and http://www.frogdot.org/mod_auth_mda/index.html Ian Bicking wrote: > Okay, I got HTTP authentication working (thanks Bill). I couldn't get > the Zope method to work quite right, as environmental variables weren't > passed on. > > Anyway, a page describing it is at: > http://webware.colorstudy.net/twiki/bin/view/Webware/HttpAuthentication > > Ian > > > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss -- Bill Eldridge Radio Free Asia bi...@rf... |
From: Ian B. <ia...@co...> - 2002-05-11 20:28:00
|
On Sat, 2002-05-11 at 08:13, Bill Eldridge wrote: > > Is there a way to get APache to use WK for authentication > even for non-WK pages using something like this? > It looks like someone's been working on something > similar here: > > http://mod-auth-script.sourceforge.net/ > > And another at: > http://www.unixpapa.com/mod_auth_external.html The second one mentions yet another version that supports the authenticator program being queried over a socket -- with the multi-protocol/socket-listening Application of the future, you could hook this up to Webware fairly easily. Otherwise, it might be possible to route a request through Webware, and then have it do an internal redirect to the actual location of the resource. However, this may be insecure -- if you knew what the ultimate destination was you could short circuit the authentication. Unfortunately, I don't think you can do an internal redirect to a resource not available as a normal URL (i.e., just in the filesystem). If you could (and you very possibly can, I don't even really understand what Apache's doing with internal redirects), that would provide a solution as well. > As well as other Apache modules: > http://modules.apache.org/search (search for auth). The problem with the entirely in-Apache method (via mod_auth_whatever), is that it doesn't provide a good way to which documents are visable by who -- they only deal with identifying who's trying to access the document. Of course, it's easier to hook up that part from a dynamic page, all you have to do is throw a 401 as needed (or maybe 403, if they've logged in and still don't have the permission). > Note that Mozilla now supports Digest Authentication. > http://www.mozilla.org/projects/netlib/http/ > http://www.mozilla.org/releases/mozilla0.9.7/#new > > Digest Apache module here: > http://www.berlinonline.de/wissen/computer/linux_tips/os/ > and > http://www.frogdot.org/mod_auth_mda/index.html I don't feel like you can offer both possibilities to the client -- though I don't really know. Ideally, I'd offer both, and if the client supported digest it'd use that, and if not it'd use basic. But there's not nearly enough support for digest to do it exclusively. I dunno. Ian |
From: Bill E. <bi...@rf...> - 2002-05-12 16:49:54
|
Ian Bicking wrote: > > Note that Mozilla now supports Digest Authentication. > > http://www.mozilla.org/projects/netlib/http/ > > http://www.mozilla.org/releases/mozilla0.9.7/#new > > > > Digest Apache module here: > > http://www.berlinonline.de/wissen/computer/linux_tips/os/ > > and > > http://www.frogdot.org/mod_auth_mda/index.html > > I don't feel like you can offer both possibilities to the client -- > though I don't really know. Ideally, I'd offer both, and if the client > supported digest it'd use that, and if not it'd use basic. But there's > not nearly enough support for digest to do it exclusively. I dunno. This was just to add to your comment on the page that only IE5, Opera & something else offer Digest authentication. Mozilla is a big add. Netscape 6 doesn't seem to support Digest though. The SSL route is probably how people will continue to go. -- Bill Eldridge Radio Free Asia bi...@rf... |
From: Ian B. <ia...@co...> - 2002-05-11 20:23:02
|
On Sat, 2002-05-11 at 07:20, Bill Eldridge wrote: > > Some of the issues mentioned in this list about > getting various info from Apache into Webware > might be addressed in Apache 2.0, specifically: > > The second advantage over Apache 1.3 is filtered input/output (I/O), > which allows one module to modify the output of another module. An > often-requested feature of Apache 1.3 was for CGI scripts to output > SSI tags. This wasn't possible in version 1.3, however filtered I/O > allows this to work in Apache 2.0. > > It might be worthwhile thinking about aligning Webware > with Apache 2.0 rather than trying to get more out of 1.3. Right now Webware isn't really aligned with Apache at all -- there's no critical features for Webware that are provided by Apache. The one that comes up a lot -- mod_rewrite -- is more for dealing with problems due to the heterogeneous nature of the typical Apache server. So the Apache-specific function is really Apache-specific, and you don't need it for a standalone server. And someday IIS might work well -- it's close, it just needs someone to really need it to work and do that last bit of effort. > http://www.onlamp.com/pub/a/apache/2001/04/26/apache_2.html > > You can also have one Apache module now call into another > one, so you don't necessarily have to replicate features: > > http://www.onlamp.com/pub/a/apache/2001/09/27/apache_2.html I'm not sold on many of the features of the modules... it's so much easier and more powerful to use Python, and you can be so much more expressive in Python code than you can in the conf file. Simple features, like mod_gzip, could be done in Webware just fine if we just did it. Complicated features, like DAV, couldn't be sufficiently controlled from the Python side if they are implemented in an Apache module. Ian |
From: Bill E. <bi...@rf...> - 2002-05-12 16:47:49
|
Ian Bicking wrote: > > > I'm not sold on many of the features of the modules... it's so much > easier and more powerful to use Python, I was more interested in getting various variables out of Apache and passing them on rather than trying to do anything in an Apache module. Even the rewrite stuff seems like it'd be much more straightforward and controllably dynamic (without restarting that server) if done in Python. and you can be so much more > expressive in Python code than you can in the conf file. Simple > features, like mod_gzip, could be done in Webware just fine if we just > did it. http://python-bz2.sourceforge.net/ as one alternative. -- Bill Eldridge Radio Free Asia bi...@rf... |
From: Ian B. <ia...@co...> - 2002-05-13 19:49:52
|
I think you probably meant to post this to the list... On Mon, 2002-05-13 at 11:46, Terrel Shumway wrote: > On Sat, 2002-05-11 at 13:27, Ian Bicking wrote: > > > > Otherwise, it might be possible to route a request through Webware, and > > then have it do an internal redirect to the actual location of the > > resource. However, this may be insecure -- if you knew what the > > ultimate destination was you could short circuit the authentication. > > Unfortunately, I don't think you can do an internal redirect to a > > resource not available as a normal URL (i.e., just in the filesystem). > > If you could (and you very possibly can, I don't even really understand > > what Apache's doing with internal redirects), that would provide a > > solution as well. > > Feature Request for mod_webkit NG: > > Allow an internal redirect to an otherwise inaccessible file, possibly > filtering the result through other modules (e.g. mod_gzip, mod_xdelta, > mod_patch[1]). Yes, I had thought about this as well, and I thought I had put something on the Wiki, but I can't find it now so I must have been imagining that. Instead of mod_patch, I imagine you could use SSI, mod_layout, or somesuch thing. The adapter should include an environmental variable that indicates it supports this feature, and then HTTPResponse should have a method like serveFile or writeFile (writeFile if a mod_patch-ish thing was to exist), and it would either use the special header if the adapter supported it, or use the standard read/write loop if not. An adapter also may not support this if it was not on the same computer as the AppServer. This *may* already be possible with internal redirects and fancy mod_webkit rules (I believe you can write a RewriteCond that only catches internal redirects, for instance). But that's also not portable in the same way this would be. > How? maybe don't use the normal redirect mechanism at all, but allow > mod_webkit to just sendfile("path/to/private/file/cache/file.html"). > > > status: 200 Ok > [normal headers] > content-type: application/x-rpm > x-webkit-sendfile: wkcache/foo/bar/fj823270jf/myfile-299.00.2-1.src.rpm > > or > > status: 200 OK > x-webkit-patch: source=wksource/foo/templates/myfile.template;id=0 > x-webkit-patch: source=wkcache/foo/f3432/myfile.partial;id=1 > x-webkit-patch-length: 504 > > [patch instructions here ..., probably with additional source data at > the end.] > > > Why? For the same reasons you would use apache/mod_webkit in the first > place instead of a native python HTTP listener. > > (This message is mostly a note to myself for when I get around to > porting mod_webkit to apache 2.0 (a long way off right now), or to > anyone else who may beat me to it.) > > -- Terrel > > > > [1] mod_patch is currently vaporware. The idea is to merge content from > multiple sources, often one from the filesystem (the base template or > cached partial result) and another from webkit (customizations based on > request and session data). > > |