Separation of authentication from authorization?

[Shane Curcuru <as...@shanecurcuru.org>]

(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?

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

Re: Separation of authentication from authorization?

[Sam Ruby <ru...@intertwingly.net>]

On Mon, Jun 5, 2017 at 10:33 AM, Shane Curcuru <as...@shanecurcuru.org> 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