Thanks to everyone for some really good information. @Marc Paterman, svn's apache module is dav_svn, so it's definitely DAV related. I'm not sure if it simply supports DAV or if that is its native mode; I suspect the former.
On Tue, 2009-05-12 at 10:05 +0200, Peter Schober wrote: > Ross et al., > > I'm not sure I understand the actual question at hand -- you have (or > want to write) a Smalltalk-based application that runs in it's own > webserver, and proxy to that with httpd? Yes. As you note below, proxying implies further difficulties getting authentication info from Apache to the my web app. It sounds as I can either place it in carefully cleaned http headers or rely on some other single sign on technology. > Where is the SVN access > happening? From the Smalltalk app? From httpd? Both, though the smalltalk app is only going to talk to svn via http. There are potentially several scenarios (though I could probably dispense with some of them): 1) Someone with a subversion client on another machine accesses the svn server via http. 2) Someone uses a web browser views the respository through a web interface like ViewCVS or Trac. 3) Someone browses to our custom app which redirects tham to 2) or else presents material from 2) as an embedded page. 4) Someone using our custom app triggers some logic which causes the custom app to access the repository as a svn client (e.g., to get a changelog). The custom web app processes the results in some way and displays the results. The custom web app would also be accessing svn via http. > Is this SVN-webapp something like ViewCV or Trac? Yes (2 and 3 above). > Is it under your > control (source available, permission to modify)? COST or homegrown? All the software should be under our control and open source--that is, all the suff I've discussed above. If the central IT ever gets its single signon going it will be effectively out of our control, and apparently closed source. > Find a few generally off-topic remarks below ;) > > * Ross Boylan <r...@biostat.ucsf.edu> [2009-05-12 04:35]: > > Well, I don't even know how to do that step, though the reference to > > mod-cas by Nick Owen may be a clue. > > Academic organisations should definitively look into running > Shibboleth (mod_shib in httpd, but there's a fastcgi responder as well > as a M$-IIS ISAPI filter, for those less lucky) as campus web SSO > system, since it also does federated websso (via SAML2). I can pass the suggestion on, but they apparently did an exhaustive review before settling on their solution. Their requirements were undoubtedly complex. For my purposes, their choice is effectively like the weather: I just have to live with it. However, if it's the best route, I suppose we could do a single sign on that at least covers our little ecosystem. When I started thinking about this I thought that meant going with LDAP, but I guess that in itself just assures the different apps have the same id/password. Ideally, I want the same id/password, and I want it only asked once. Incidentally, solutions requiring the human clients to have more exotic technologies (certificates, ssh) are probably out. .... > > > It's not written! But the natural way it works is to have a login page. > > After login, the id is saved on the server and associated with the > > session (using the Seaside framwork). > > First thing that'd need to go is the login page (see above) ;) I've seen mention of apache using a login page, rather than the usual popup. Is there a way to do that? It might have a nicer feel for users. > Looking at Seaside it seems this comes with it's own VM and webserver, > so you'd need to reverse proxy to this from httpd and do all the authN > and authZ there. Which is fine, but you won't get REMOTE_USER to your > Seaside app via mod_proxy_http (as you would via AJP), also envvar's > won't help, which leaves HTTP request headers (which are easily > spoofed, so would need to be clean by httpd before proxying to > Smalltalk). > > > Funding cuts also seem likely to delay rollout of the single signon, > > even if we wanted to use it. > > There are several Free Software offerings, some of which are rather > easy to setup and maintain[1] if you have the IdM infrastructure in > place (directory service or database with up to date data/accounts for > your population, a way to authenticate all users). They've bought and partly rolled out the software, so I think it's the cost of people's time, rather than the software, that is the main difficulty. Stopping part way through may be a false economy, but the state of California has been doing a lot of those recently. > > Check out http://www.nmi-edit.org/started/index.cfm or EDUCASE and > related Internet2 activities (e.g. "CAMP" workshops). Thank. Ross --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
