[
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