On Mon, Jun 5, 2017 at 10:33 AM, Shane Curcuru <[email protected]> wrote: > (Note to self to coordinate/update the docs) > > Is there a simple way to have a single cgi attempt to authenticate > committers, but if that fails, to fall back to displaying the page > anyway, just without any data in ASF:Auth? > > The user case is a form that anyone can use, but if a committer is > logged in, they get additional options (and the endpoint can store that > it was submitted by a specific committer). > > Or is that silly, and I should just have separate cgis?
Nothing is silly, and even things that start out hard can be made easier by refactoring. There are alternatives to HTTP auth (for example, your own custom form or things like OAuth like ponymail uses), but I'd suggest avoiding them for any tool that might need access to a password later (for example, to issue a svn command or to call an LDAP API). These other approaches generally require you to keep a database of sessions, and to issue cookies. If you stick to HTTP auth (and probably even if you don't), I don't think the scenario you describe in your first paragraph can be done: it needs to be the other way around. Display the page like you would for an unauthenticated user, and only prompt for a password if the user asks you to do so. This is the approach that ponymail takes (and, FWIW, I'm still caught off-guard occasionally by that choice). Unofficially, I tend to think of comdev as outward facing, with applications like the phonebook. And Whimsy as inward facing, with applications like the roster tool. Both are driven by the same data. And both contain tools to prepare pre-digested and selective subsets of things like LDAP and DOAP for consumption. - Sam Ruby
