SUSI.AI has 7 different user roles (bot, anonymous, user, account creator, reviewer, admin and bureaucrat). Users are classified based on these user roles. To distinguish each user’s identity, SUSI Server uses email id as the key. So before using any of the services user needs to login with SUSI. In this blog I discuss how SUSI makes login a smooth experience for the users.
Every app should provide a smooth and user-friendly login experience, as it is the first point of contact between app and user. SUSI Server uses DAO in which accounting object is stored as JSONTray. The Susi server provides the required API endpoints to its web and mobile clients.
Login service across various web, iOS, android and IoT client allows users to login, logout or to check their login status. Login endpoint uses the HttpServlet class which provides methods, such as doGet and doPost, for handling HTTP-specific services.Thus the LoginService class was inherited from AbstractAPIHandler and implement APIhandler interface. In Susi Server the AbsrtactAPI handler extends a HTTPServlet which implements doGet and doPost ,all servlet in SUSI Server extends this class to increase code reusability.
The AbstractAPIHandler checks the permissions of the user using the user roles of and comparing it with the value minimum base role of each servlet. Thus to specify the user permission for a servlet we need Override the getMinimalBaseUserRole method.
Below given is the end point at which requests are made.
Login servlet handles various types of requests. Requests can be made in following ways with different parameter lists:
- Login with given user email id, password, type of login = access_token
In this type of request an access token is created and stored with some expiry time, by default the expiry time is set to one week. The generated access token is then sent as a response from server with success flags having value true
- Login with given user email id, password, type of login = session
It creates a new browser session for the logged in client based on the session id of the current session associated with it. if there is no session associated with the request an exception is thrown.
- Login with given user email id, password, type of login = cookie
In this request it sets a long living cookie, creates random string as token with long age and finally write cookie to database with expiry time as age of the cookie.
- Login with given user email id, password, type of login = check password
For this request server checks if the password is valid by comparing it with the hashed password, if the comparison fails an exception is thrown for client to display “Invalid Credentials” Otherwise response is returned for successful login of the user.
This is how Login Service is implemented in SUSI Server. Try it out, using web and mobile clients. To add more skills or modify the existing ones visit skills.susi.ai. For more information and complete code take a look at Susi server and Susi_Skill_cms and join gitter chat channel for discussions.
- Read more about Servlets – https://www.tutorialspoint.com/servlets/
- Read more about JGit- http://www.vogella.com/tutorials/EclipseGit/article.html
- The source code – https://github.com/fossasia/susi_server/blob/development/src/ai/susi/server/api/aaa/LoginService.java
- Read more about DAO- https://en.wikipedia.org/wiki/Data_access_object