UniverseUniversity


Home Projects Jobs Clientele Contact

uu


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UU: keeping track of user and his access



IMHO,

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 <ilya@total-knowledge.com>
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&,
UuResponse&)
  (UuRequest and UuResponse classes are derived from
Http{Request,Response}Wrapper
   classes, and add ways to access User object of the session, if
present, along
   with some other request-specific info, which we might find useful.)
Obviously,
   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.


   Ilya.





--
Alexey Parshin,
http://www.sptk.net

Authoright © Total Knowledge: 2001-2008