On 10/4/07, Toni Mueller <[EMAIL PROTECTED]> wrote:
>
>
> I strongly suggest using the following authentication scheme, after
> having battled non-cooperation between several authentication methods
> for a while in a different context:
>
> You have a username/password combination set for the application that
> the application uses to request eg. authentication data from the
> database. Alternatively, you leap and implement OpenID, which "solves"
> all other problems for you.
There are a few real reasons for going with PostgreSQL native accounts.
These include:
1) Ability to use any authentication system PostgreSQL can connect to
(Kerberos, LDAP, PAM, etc. It shouldn't be too hard to write a PAM module
for OpenID also...). If you want to authenticate users against NT4/Samba
servers, you can do that. If you want to authenticate against Active
Directory, you can do that.
2) Security and permissions apply regardless of how a user connects to the
db.
Now, when the user is on the login screen, you grab his username and
> password, hash, and compare with what's in the database. OR, you use
> that data to authenticate to the database (should have pretty much the
> same effect). If authentication succeeds, you open a session and set a
> cookie to the user. Doing that session+cookie stuff has its own
> pitfalls, but I've not yet been able to combine eg. 2x "HTTP Basic
> Auth" or 1x "HTTP Basic Auth" + 1x "HTTP Digest Auth" (eg. when working
> through a so-called SSL-VPN).
There is a major difficulty here. You can't use the database to enforce the
user's permissions in this case in a robust).
What you can do, however, is to modify the cookie on every request, so
> stealing a cookie would not necessarily grant immediate access (it
> would be invalid once the user has clicked another link). The big
> drawback to modifying the cookie on every request is that this disables
> working with several tabs open at the same time. OTOH, SSL should be
> mandatory anyway and make cookie-stealing almost a non-issue.
1.2 modifies the cookie on every request which causes some issues with tabs
(i.e. 2 documents cannot load at the same time). 1.3 is going to require
authentication information and a session cookie for every request but the
session cookie will be static.
JavaScript should IMO be out of the question, however, and only be used
> for pure convenience functions. Accessibility should be a core
> requirement.
JavaScript in this case is used to provide an alternate login screen to
those browsers which can use AJAX. If Javascript doesn't exist, the login
becomes a 2-step process (select your company, ok now provide
username/password).
The big issue I am runnng into is that Firefox and presumably other browsers
prompt for HTTP Auth credentials when the XMLHttpRequest object receives a
401. I am working on a solution to that at the moment. (I am trying to do
something with minimal misuse of the standars.)
Best Wishes,
Chris Travers
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
