Closed GoogleCodeExporter closed 9 years ago
I was already thinking that when a user tries to login, if they already have a
account, they are logged in, and they can do stuff, otherwise they are sent to a
registration page. The authentication of the openid is already taken care of by
the
openid provider. I can see no trouble with users trying to use their openid
for more
than one user as the system I am thinking we want will not allow this. If they
use
their openid then, the previous registration will be used and the only way they
can
use it for any other account with our system, is to delete their old account
first.
Also Jordans implementation won't allow for duplicate keys, ie openid_url being
a
primary key here. Also any registering which involves attaching a openid will be
authenticated through the openid provider first so no unauthorised use of a
openid
can be blamed on our system.
I am already part the way towards this task with the user management stuff.
Half of this can be done without using any UI components.
Original comment by terrasea
on 13 Aug 2008 at 5:45
The welcome.jsp page is getting to complicated. It's trying to handle to many
things
at once. Is it openid log in, is it a newUser, so add user to database. On top
of
that is it going to handle username and password log in. These are to many
things to
be handled in one page. It has to be split up and have the welcome.jsp serve
only
one function, and that is to welcome the user to the site.
The solution, take all these different tasks out of welcome.jsp and handle them
separately with their own special purpose handler. In this case I propose to
make
them handled by a separate HttpServlet for each of them. OpenIdConsumer, for
openid
log in, NonOpenIdConsumer for username and password log in, and
RegistrationProcessing for adding users to the database.
The Logging in of users should be straight forward.
The registration, while it sounds easy enough, if the requirement to allow
someone to
register using their openid, and the authenticating this, is proving to be a
tricky
issue. The authentication involves redirecting to the provider, who then
redirects
back to use the relying party. The problem being that any form data is lost, I
think. it maybe able to overcome this by placing any data into the session
attribute
list. It doesn't sound ideal, but it maybe the easiest to implement.
The other, invloves registratoion. Does it handle both openid registration and
username and password registration, or does it handle them separately. It
would be
easier in some respects to keep them separate, but there is too much of a cross
over
there, as both involve adding user email, phone number and username. Tt will
have to
stay that way for the moment, if not for the rest of this project. The solution
maybe more complicated then the issue it is trying to solve.
Original comment by terrasea
on 20 Aug 2008 at 11:42
The logging in using either OpenId or username, password has been implemented.
They
seem to work ok. There are two separate servlets to authenticate users.
OpenIdConsumer for handling Openid log ins and NonOpenIdConsumer for handling of
username and password log ins. The servlets set a couple of session attributes
"user" which is a User instance and "signedin" which indicates a user using this
session has logged in. The requirements for using these servlets are documented
in a
wiki page as well as a separate wiki for documenting what the servlets put into
the
session attributes.
The registering of new users has yet to be implemented.
Original comment by terrasea
on 22 Aug 2008 at 9:52
Registration has been implemented.
It allows for OpenId registration from both trying to logg in without a account
and
from the registration page. In the registration process for OpenId, it will
make sure
the user is authenticated before registering them in the database. This was a
little
tricky trying to account for authentication from the logg in page or not being
authenticated, so needing to go through this process if they start from
'register.jsp'. Also making sure the OpenId they enter into the registration
page
equals the one they used to authenticate with if they have authenticated
already.
The username and password registration process is also implemented. This was
the
simple one to do.
Supporting both is a problem that has not gone away, in my opinion, yet.
* If a openid that was entered in the registration page does not match the one they
already authenticated with how is this handled? I have not figured a solution
for
that one yet.
* How are error messages passed from the registration or authetication servlets
passed onto the user?
* Is it neccessary to have the registration for both openid and username and
password done on the same page? This is going to confuse the user into
thinking they
need to have a password to use this site, as well as a openid. Also if the
types of
registration can be put on separate pages, in my opinion, it would make things
simpler and less likely to produce errors given the number of conditions being
checked for.
Original comment by terrasea
on 28 Aug 2008 at 9:35
Hey James I agree that to make things less confusing for the user it might be
better
to have 2 link in the right menu "Register using Open ID" after the Log In Via
OpenID thing and "Register using username and password" after Log in using
Username
and password. Feel free to separate the two out ie create 2 registartion pages
where
the only difference is the open id and username/password thing.
And just to confirm the username/password thing and openid are both working for
me
so that's good.
Original comment by parul2...@gmail.com
on 28 Aug 2008 at 11:28
The registration process has been cut in two. There is one for those who use
OpenId
and one for those who want to use Username and password.
Original comment by terrasea
on 31 Aug 2008 at 10:34
When you get redirected to registration page if the OpenID is not in our
database
the Registration page does not have the CSS layout as our other Registration
page.
Original comment by parul2...@gmail.com
on 31 Aug 2008 at 9:11
Fixed defect
Original comment by terrasea
on 7 Sep 2008 at 1:51
Closed issue by mistake, now reopening it I hope
Original comment by terrasea
on 7 Sep 2008 at 4:46
Changing this back to a task, from defect, which it is not.
Original comment by terrasea
on 10 Sep 2008 at 10:26
Registration and Logging in Via OpenID needs to work on Massey Server
Original comment by parul2...@gmail.com
on 16 Sep 2008 at 3:29
Fixed the issue withthe Massey server. The OpenIdConsumer needs to be able to
connect with the OpenId Providers and was being blocked by the massey firewall.
Fixed this by getting all connections OpenIdConsumer makes to be made through
the
Massey proxy server.
Original comment by terrasea
on 23 Sep 2008 at 11:34
Authentication and registration errors need to be displayed to the user. At the
moment all that happens if the authentication or registration happens is they
get
redirected backt to the index page, with no explaination as to why.
I have started work on this.
Original comment by terrasea
on 23 Sep 2008 at 11:37
Done by James
Original comment by parul2...@gmail.com
on 14 Oct 2008 at 8:59
Original issue reported on code.google.com by
parul2...@gmail.com
on 13 Aug 2008 at 3:29