wiki:s2s-login-functionality

Version 16 (modified by mira, 15 years ago) (diff)

--

Error: Macro BackLinksMenu(None) failed
compressed data is corrupt

Error: Macro TicketQuery(summary=s2s-login-functionality, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed
current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

The user should have the opportunity to:

  • Login
  • Logout
  • Register
  • Change his account data
  • Preview his data
  • Recover forgotten password
  • When entering the site user should be logged in as anonymous. This means that he have accesses to all public data.

The goal of this task is to provide this functionality.
Overall the server itself should be configurable. Following properties should be adjustable:

  • Port - the default one is 8003
  • Mail that is used to send messages to the user. (All needed information for this to work) This won't have default value.
  • User activation via mail - the default behavior for this is to be disabled, however users should have the ability to enable this functionality. This way the user became active immediately after registration.
  • Rights to anonymous user - some small(local) servers may not need users. As default this user have only read rights.

Task requirements

  • provide
    • Login page
      • Two text fields for password and email
      • Back button
    • Logout functionality
    • User account data page
      • ability to change/add/remove screen name
      • (optional)ability to add additional emails
      • ability to change password (may require additional page)
      • ability to add/remove avatar image
      • editable additional info
      • notification for personal data publicity (label)
      • (optional)should provide a way to manage visibility for user data
      • link to preview data page
    • User details: Shows user info as the others sees it.
      • Should show avatar, screen name, emails(depends on user input), description, list of (public) groups that the user is include in (this won't be implemented in this task), list of (public) owned resources.
      • If the user views his own page, then all resources and groups are shown. Also should have the ability to remove resources and to leave groups.
      • The url for this page should be human readable. One opportunity is [DOMAIN NAME]/users/[user registration mail with "_" instead of "@"]/
    • Register page: Should contain text input controls for all properties that the user can give input on
      • email - required
      • password - required
      • repeat password - required
      • (optional)upload image control - with description of size limitation
      • screen name
      • description
    • Forgotten password page
      • Conformation page that show message to the user that the new password is sent to the mail

Task result

  • Code

Implementation idea

  • Use existing visual language and extend it to fit the requirements

How to demo

  • Go to server page
  • Register new user
  • logout and login again
  • Change some personal data
  • request password change

Design

User name

Change the register and login pages to ask for e-mail instead of userName and use it as the unique identifier of the user. This should be achieved by generating the unique part of the users ref from its e-mail information. The email could be transformed to a string that contains only symbols allowed in ResourceRefs and then it could be used as part of the location to the user.

Password

For now we could keep the password in plain text and on login compare the provided password with the original one. In future it is better to generate a hash code by the pass and keep only it in the database.

Screen name

The user will be allowed to set the name that is presented to the other for him/her. This is done in the screen name field. If it is not set the user is referred to by its e-mail address.

Web UI

This task is basically implementation of jspx files and HttpRequesHandlers for their logic. The present design of the WebUI and WebApp modules is good and should be kept and just extended to supprot new functionality. There will be added:

  • Login page
    • Two text fields for password and email
    • Back button

There will be common method used for the login functionality. The handler for this page should extract and validate the data of the request. The it should call this method to login the user.

  • Forgot password page: Sends the user mail with his password, after the
    • Label that describes expected user behavior and what will happen after send button is clicked.
    • Text field for users mail
    • Send button

The handler will check if such user exists and if so send the original password back to him/her. For this I will use the java.mail api. The mail, smpt and port for this functionality will be stored in a configuration file. For this I will use the ConfigKey.

  • Notification page
    • Template page that is shown for few seconds with message inside it. Announcing errors or success.
  • Registration page
    • Two columns with text fields for: e-mail, password, confirm password, screen name, description
    • [OPTIONAL] Upload control for avatar (image)
    • Labels that point the mandatory fields
    • Labels to point any restrictions (image size etc.)
    • Error messages appear on top of the page. Error message could contain the following error info:
      • Wrong mail
      • Short password (insecure)
      • Wrong password conformation
      • [OPTONAL]Unable to upload image

Since those fields are slightly different from the initial ideas for user information to be stored, the UserR4 keys and the RegistrationFormBean fields should be changed accordingly. The registration handlers will deal with all fields validation. If all requered information is ok the user will be created in the users folder on the server. He/she will also be loged-in by the common method used by the login handler. If the information is not ok the handler provides error messages and returns a RegistrationFormBean that contains the valid information. This way the set fields of the bean are used as default falues for the registration form. The email and password validation will also be extacted in a common methods.

  • Edit profile page
    • Basically same as the registration form, with a few differences. First of all the mail text field is replaced with label. Second instead of "password" and "confirm password" fields we now have - "password", "new password", "confirm new password". Additional link to profile view is added.

The handler extracts all the given information and changes the stored data for the user that is curently loged in. There is additional password check.

  • My profile page: Displays users info
    • Same as registration page, but instead of input controls we now have labels and image

The handles simply colects all the information for the currently loged in user and sends as a regues parameter in the RegistrationFormBean.

All common methods will be encapsulated in a util class - RequestHandlerUtil.

Implementation

The configurable things for the server from this task are: the smtp hostname, the smtp port, the email and pass from which to send support mails and a flag showing that there is no email conformation needed for the registration functionality.

The RegistrationFormBean is a bean used to transfer information from the servlet to the jspx pages. It has user-name, email, password, screenName, description and avatar ref.

The implementation is done according to the design at the branches/private/mira/security with some exceptions:

  • The password will not be saved in plain text. The thing that will be saved is the md5 code of the provided password. When a user forgets his/her password a new one will be generated and send via e-mail.
  • After discussion with experience team following changes will be included inside the implementation
    • Instead of email, users will log in with user name. This field will appear inside registration, edit profile(not editable) and detail view sections. However the email remains as required field.
    • The url for users detail view will appear in the following format [Domain name]/users/[User name]/
    • Рespectively the group name became [Domain name]/users/[Group name]/
      • Note that the group name will be unique for all groups as well

I had some problems sending mails using the java mail api. One of the things I found important is to set the properties "mail.smtp.auth" and "mail.smtp.starttls.enable" to true. Then I had to create an Authenticator that simply returned a PasswordAuthenticator with the correct username and password for the supprot email.

Testing

(Place the testing results here.)

Comments

(Write comments for this or later revisions here.)