UniverseUniversity


Home Projects Jobs Clientele Contact

uu


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

Re: User registration/authentication



Yes, we can call login() proc as many times within the connection as we want. It would simply replace the user data in session_info table.

2007/4/3, Ilya A. Volynets-Evenbakh < ilya@total-knowledge.com>:
That works for me, presuming empty login name works, and that
we can still authenticate later on, during same connection, with
non-empty one.

Alexey Parshin wrote:
> The other possible solution is - if we don't have a login, we call
> login() proc with empty login name. In that case, session_info table
> wouldn't have any records, and therefore it would be no access to
> privileged tables. It would be also no 'current user' as such and no
> way to store anything.
>
> 2007/4/3, Ilya A. Volynets-Evenbakh < ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>
>     Alexey Parshin wrote:
>     > 1) In order to open the connection we need login and password. When
>     > you get a connection from the pool you must provide both for login.
>     > This operation is pretty quick, so performance isn't an issue here.
>     Last I remember, when we talked about database-side of this did
>     not require
>     log in for every operation (i.e. there are some read-only ones that
>     don't need to be authorized)
>     This means, as Sergey correctly noted, that username/password aren't
>     always required.
>     I guess we may provide two getConnection() methods - one with
>     login/password pair, and one
>     without. I would also add an explicit login(user, password) to
>     connection, which would perform
>     our login stuff, if it wasn't performed already. Also, in this case,
>     release() method should only
>     do logout clean-up if login was performed.
>     >
>     > 2) For not logged-in users, we can create default user with empty
>     > password that you can use for such users.
>     This isn't the case where "default" record will work properly. Think -
>     we have preferences associated
>     with each user. What will happen if someone changes preferences while
>     not logged in?
>     There are many other cases like that. In any case - as mentioned above
>     it's not needed at all.
>     >
>     > 2007/4/3, sergey@total-knowledge.com
>     <mailto: sergey@total-knowledge.com>
>     > <mailto:sergey@total-knowledge.com
>     <mailto:sergey@total-knowledge.com >> <sergey@total-knowledge.com
>     <mailto:sergey@total-knowledge.com>
>     > <mailto: sergey@total-knowledge.com
>     <mailto:sergey@total-knowledge.com>>>:
>     >
>     >     I have a trouble dealing with authentication functionality
>     the way
>     >     it's
>     >     defined now, so I'm asking for your guys opinions.
>     >
>     >     In order to get connection from the pool I need to perform an
>     >     authentication inside of UuDbPool::getConnection().
>     >     In order to do that I need to pass login, password, server and
>     >     sessionid
>     >     to the getConnection().
>     >     I cannot get those parameters from DB b/c connection will be
>     >     opened only
>     >     after authentication in the pool. So where do I get them?
>     >     sessionid is no problem, I get it from HttpSession.
>     >     I can save login, password, server in HttpSession object after
>     >     successful
>     >     login/registration, but I don't think it's a good idea. If I
>     save
>     >     userid
>     >     in session, then I need a DB connection to get login, password,
>     >     server
>     >     from DB, but the connection is not available for reason I
>     >     explained above.
>     >     If I use sessionid as the key parameter to get user
>     >     credentials(which is
>     >     the best way since I won't need to save anything in
>     HttpSession),
>     >     then we
>     >     need sessionid in regular(not temporary) table in DB, but still
>     >     need the
>     >     connection before calling getConnection(). But in this case,
>     if we
>     >     change
>     >     login() stored procedure to get only sessionid as the
>     parameter,
>     >     we won't
>     >     need a connection to DB before calling getConnection().
>     >     Imho it's ok to have sessionid as the only parameter to
>     login(). The
>     >     authentication will be done at login time, sessionid will be
>     saved
>     >     in DB
>     >     for this user, then login() will check if user exist using
>     >     sessionid the
>     >     same way as it's done now using login parameter. session_info
>     >     table can't
>     >     have more than one record anyways.
>     >
>     >     Another question about not-logged-in users. The way things
>     defined
>     >     now,
>     >     not-logged-in users can never get a connection to DB.
>     >     Per specs we are going to have some pages available for
>     those kind of
>     >     users, I'm sure we'll still need to get data from DB for those
>     >     pages, for
>     >     example in left navigation bar or in Repository. How are we
>     going
>     >     to deal
>     >     with that?
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     > --
>     > Alexey Parshin,
>     > http://www.sptk.net
>
>     --
>     Ilya A. Volynets-Evenbakh
>     Total Knowledge. CTO
>     http://www.total-knowledge.com
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net <http://www.sptk.net>

--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com




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

Authoright © Total Knowledge: 2001-2008