Verifying User from MySQL database in java - java

I am making a School management system. In this system, first we have to create a user which gets stored in MySQL Database of Usernames and Passwords. But I am stuck at that step where we have to verify the user. How can I do that? I just need a rough idea guys..:)

I am not sure what you mean by "verify the user" but if you mean by checking if the user is actually in the database, use SQL syntax similar to this:
select username from usertable where username = 'username';
If you have a row returned, then you know that the user is in the database.

Verifying could imply several things among :
- checking if the user exists
- checking if the combination username/password is valid for authentication
- checking if the user profile is valid to interact in your application
This list is most probably not complete

Related

How can user create unique user name

I want to create a unique user name for my users, but this will be not system generated. Users can choose his/her user name.
DB
MongoDB
Ex
Github user name
Current process
sign-up
get a verification link on the email
go to the link, like example.com/verify?token=xyz...
On verify page user can enter a user name, that user name must be unique across the DB.I don't want to keep duplicate user names.
Many websites have implemented this feature, like Github, GitLab, etc. But, I have explored some web about implementing this feature and I didn't get the desired result.
After entering the user name in step 3, the browser will make a POST request to the server.
Server will then check the DB that if this user name already exists or not, if this already exists then throw an error or process the user name otherwise.
This is working on my local PC, but I am not sure whether this will work when multiple users make a request with the same username within a time interval. Then, in this case, there may be some duplicates in DB.
case
There are two users A and B wants to create their user name on the system at the same time.
both are requesting the same user name
A: make the request for the user name u1
Server: check for A's user name is present or not in DB
B: make the request for user name u1
Server: A's user name is not present, save u1 as A's user name
Server: B's user name is not present, save u1 as B's user name
You can see, in the end, both users's haveing the same user name.
Is there any way to avoid this??
The solution depends on your Database. If you are using SQL database, you can just add UNIQUE constrain to the field, so the database will enforce the uniqueness of an attribute value in the table. The first row will be inserted while another row will fail to insert with an error that the field is not unique.
Speaking of MongoDB, you also have a unique index.
-> As the above answer suggested have a unique constraint on DB for user name and if the insert didn't happen send an error response stating username already taken also
-> We do not need to wait until the user submits the request, as the user types in the user name, call an API to check if the username already exists, and while calling this cancel the previous request which we haven't got a response back. For example when the user types vi you send a request and it is still in progress but the user has typed vig now before sending the new request with 'vig' data, cancel the previous request. ( Ans simultaneously show the status whether taken or not as you get the responses )
This improves the user experience.
-> The cancelling of the requests can be done using cancel tokens in Axios, if you are going with Axios.
For MongoDB:
If you can create an additional unique index based on a combination of fields, can't you use an additional dummy field ( which has the same data for all users), so now your username would stay unique? (I haven't used MongoDB a lot to be sure of this. )
OR this is mentioned in the Mongo DB documentation , create a proxy collection to maintain this username as a unique key, following the first segment in the below document
https://docs.mongodb.com/manual/tutorial/unique-constraints-on-arbitrary-fields/

LDAP Password reset does not respect the pwdhistory attribute

I'm using Java - Apache Directory Client API for accessing Apache DS Ldap Server using ldapConnectionTemplate.
I'm trying to implement a feature which allows the user to reset/change the password. My password policy has a password history attribute value of 5. So user will not be able to use any of the previous 5 passwords.
When I'm using the modifyPassword method for changing the password(i.e. as a user by passing current and new password), it respects the password history policy. i.e I'm not allowed to use any of the previous 5 passwords and getting password exception as expected. But when using the reset option(i.e. - only new password), it does not honor the password policy. It accepts any value(including current one) and updates the password.
How to make the reset password scenario honor the password history policy? Any ideas, suggestions and solutions are welcome.
I don't believe the behaviour you desire is specified anywhere.
The idea of a 'reset' in the sense you mean is that the admin sets it to something known, tells the user what it is, and the pwdReset attribute is set to TRUE so that the user is forced to immediately change it on next login - which you have to enforce yourself by using the PasswordPolicy request control and inspecting any PasswordPolicyResponse for CHANGE_AFTER_RESET.
There's no particular reason why the admin should be constrained by the pwdHistory, and anyway the user is going to be forced to change the password again anyway, at which time he will be constrained by pwdHistory.

Preventing Multiple Login with same login credentials

I am developing a web application that needs to prevent multiple login using the same user name and password concurrently.
If it happens on the same machine then we need to do something with the user session, but it should also prevent if they are login on different machines using the same user name and password.
What can be the best approach :-
1) should i store the user session,credentials,and IPAddress of the machine in the DB.
2) should we use the session tracking mechanism in the application itself.If so what is the best approach?
Also , We have to keep following things in mind:
1) If user close the browser without logout.
2) If session times out.
Hope it clears the question.
Besdies data base hits (which could fail if your server is broguth down without updating db) : A data base friendly way is not to hit the data base for every re login or you could get denial of service attacks that brig you dowm. Instead implement a session listener in J2EE and check if same user is logged in by looking up the user id in a cache.
If you have more than one app node then need a distributed cache with a time out same as session time out in web.xml.
Simply have a field in your database that has text that says online or offline for each user, according to whether they are logged in or not. So when someone tries to log in with that username, check the database if the field says online for that given user on submit. If the field says online, don't allow log in. Otherwise permit it.
without using a database
you can store if a user is online in a text file
$check= "onlineCheck.txt";
$fh = fopen($check, 'a') or die("can't open file");
$nowOnline= "USER678 \n";
fwrite($fh, $nowOnline);

How can I lock users out after 3 failed login attempts using JOSSO?

Im working on a project that has an implementation of JOSSO in place.
We are using JOSSO version 1.8.5.
The requirement is to lock users out of the system after 3 failed login attempts.
Does anyone know how / if this can be done with JOSSO, I've looked through the documentation but can't find any references to this kind of functionality, but Im sure it must be pretty standard functionality for an authentication application?
What we've tried so far:
- in josso-gateway-db-stores.xml weve tried changing the SQL used to retrieve users from the database from:
credentialsQueryString="SELECT username AS username , password AS password FROM users WHERE username = ?"
to
credentialsQueryString="UPDATE users SET failed_login_attempts = failed_login_attempts + 1 where username = ?; SELECT username AS username , password AS password FROM users WHERE username = ?"
The plan was to then reset the count as soon as the user successfully logged in to the system. However, it is invalid to run UPDATE sql at this point and throws an Exception.
We have also looked through the josso application to try to find hooks that we can use to implement a callback function after successful/unsuccessful login, unfortunately have had no luck here either.
Does anyone have any experience doing thsi?
Look around JOSSO authenticatorImpl which can be inherited to count the number
of tries to lock the account in a timeboxes hashtable if necessary.

openid with appengine

I am currently using federated authentication via openid in appengine - using google, yahoo, myopenid as the providers
Had a question as to what I should be storing in my db to identify returning users.
I am currently storing user.getNickname() - (for google and yahoo this returns the users email address).
User user = userService.getCurrentUser();
String username = user.getNickname();
I use this to store and retrieve user specific data.
Is this the right way to proceed? Is the getNickName() unique? I see that User also has a user.getUserId() method and a user.getEmailId() method.
should I be using user.getUserId() instead?
getNickname() - don't use this.
getUserId() - this is logical, but the problem could be if users forget which identity they used with your site (I have multiple accounts with google, plus yahoo and facebook). This could lead to creating multiple account for one person. But then, some people want this. Also, this remains the same for Google users even if they change their email.
'getEmail()` - is actually similar to ID - uniquely identifies user. CAN be different then ID if users use alias email to log in.
Anyhow, when users log in for the first time you should present them with Account Details page (like SO does). Also, you should give users ability to aggregate identities into one account.

Categories