Photo Organizer

  • Status Closed
  • Percent Complete
  • Task Type Feature Request
  • Category Backend / Core
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Stable
  • Due in Version 2.35
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Photo Organizer
Opened by Luud - 2006-11-21
Last edited by pizza - 2007-09-24

FS#119 - Single sign on

It would be great if PO could work together with the web server (assuming Apache here) to do authentication and authorization.

Apache allows for user names and passwords to be stored in a database, including PostgreSQL. For details see

Now, if we could make apache use a table in the PO database, or alternatively let PO use a table in an Apache authentication database, the authentication with apache would imply a login into PO. So if I would want to restrict parts of my website I can use Apache's authentication mechanism, and once in, I am immediately logged into PO. Thus having a single sign on policy.

Of course we could couple the user name with which the user logged into Apache as the basis for single sign on into PO, so having a different list of users for PO than for the whole website, but from an administrative point of view it seems to me to be more useful to have it in a single place.

Next, users can be assigned to groups. Thus a user that is authenticated for the website does not necessarily have to be a user of PO. Just make a PO group and any user that gets added to PO will be added to this group. Now, when we update a password in PO it will be automatically updated for the whole site.

The next thing is to get this authentication to work for other php applications as well. Maybe there is a standard solution for this available already.

Closed by  pizza
2007-09-24 16:16
Reason for closing:  Implemented
Additional comments about closing:  The framework is now complete, including the "auto-registration" of externally-authenticated users. The only "authentication method" currently implemented is the existing PO-DB system, but adding external mechanisms is now possible.
pizza commented on 2006-11-21 15:19

This sort of thing is one of the motivations for the session_id rewrite. Once that's all happening in one place, it's far, far easier to switch out session management and authentication mechanisms. See the related tickets (#111, #93).

I definately want to split apart the user info / authentication / session stuff, which is currently in the same table..

pizza commented on 2007-07-24 12:41

The basic problem is that we have our own per-user account info that has to be created and/or maintained independently of where the authentication takes place.

There is an additional problem -- what about the case where an external entity also controls whether or not the user can use the photo organizer? The base http auth model doesn't handle this.

Discounting this, it's a pretty straightforward feature to implement now. The login page tests to see if the http auth tokens are valid, and if they are, create an account for them on the PO site if necessary, and otherwise the usual rules apply.

Another wrinkle here is that we'd need to continue checking the http auth tokens on each request, not just "login", because the instant they lose authentication, we need to revoke their access to the site.

pizza commented on 2007-08-21 04:28

r1625 has most of the necessary work implemented to support this.

All that remains is finishing the code that automagically "registers" authenticated users.


Available keyboard shortcuts


Task Details

Task Editing