Re: UU: keeping track of user and his access
- To: firstname.lastname@example.org
- Subject: Re: UU: keeping track of user and his access
- From: "Alexey Parshin" <email@example.com>
- Date: Mon, 10 Nov 2008 07:09:16 +1100
- Delivered-to: mailing list firstname.lastname@example.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=X/s1OGlWrPurmg/vLMG/Jj6knBIxii9Uh7ar40tPvoI=; b=hZoKY8WeC5QxcQNhDC7Y5N2p3zoOOo/YXQ0sIxnTFh3enxlw9MhsxchZjZWmQRo+uK tfQYFwlUTzuNJOTA0yD9jxlFhd49AYOGaoHnNVwNZ4fNlTq8s90OeWBnrQ7N5GZroX1h IrzRRwEfaoPmoQG6i6E6P2sIxvdz8Ihnml5/0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=E4lfkegN+6qv9XXQbUQ9WyGr/OM6Skw3/CL4IPCJx4sUhDt74ozGo0SbO1tSlUIgvw CFbXDp7kRUiqmo/68HXknlbRf1Af8ZJcPiu2tnFUUsy/8lP0CDkIT3dSQ5Z34moHeMoL MmtZVjArzJ0o7JDnrdxcTJIrTNDDtlfDY1aXw=
- In-reply-to: <4916CC3C.email@example.com>
- Mailing-list: contact firstname.lastname@example.org; run by ezmlm
- References: <4916CC3C.email@example.com>
In current implementation of UU, one can get on the certain page only by two ways:
- login page, then navigation
- typing in the page (servlet) name
Since any page that requires access also requires some POST parameters, second case can't show anything useful. Therefore, "no login" redirect can always just go to the login page. I do plan re-organising of login functions this week, however.
Access to the object is a totally different matter. Incorrect object modification request would throw the exception - and this generates an error message. Also, since any object manipulations are performed with controls, we can always limit the controls when generate a page. For instance, the 'Edit' button isn't shown or disabled if user can't edit the object.
2008/11/9 Ilya A. Volynets-Evenbakh <firstname.lastname@example.org>
There is an important thing I want to change in the way
libui is organized. Right now every page has to check
for login info explicitly. Then each page does something
own (usually just gives an error message).
What I think should happen in case of access error, is
redirect to the login page, followed by redirect back to
the source page, after login is done. This is in case user
wasn't logged in at all. If, however, user was logged in,
but doesn't have access to the relevant action on an object,
he should get a message which describes ways to get a hold
of such access. For example, if someone tries to edit a topic,
which he/she doesn't own, a message with contact info of
owners should be displayed.
The first part can be achieved as follows:
1. We implement UuServlet::service function, which will _never_
be overridden by derived classes.
2. UuServlet::service() first retrieves user info
3. There is abstract virtual bool UuServlet::access(User*)=0; function
4. UuServlet::service calls access(User*) function (NULL means
no login info available)
5. If access returns false, we save current page in session attribute
and redirect to the login page
6. If access() returns true, we call UuServlet::service(UuRequest&,
(UuRequest and UuResponse classes are derived from
classes, and add ways to access User object of the session, if
with some other request-specific info, which we might find useful.)
this service function is abstract as well.
We might be able to satisfy second requirement, by wrapping whole
access() and service() calls into a try/catch block, and providing
special UuAccessException, which can be thrown by either of these
functions, in case current user doesn't have enough access for current
action on current object. In the handler block for the exception we could
forward to a special CSP.