I am using symfony2.0 secured login for my login page.
I have a column name blockstatus in my login table which contains value 1 (blocked user) or 0 (active user).
I need to check username, password and also blockstatus column (0 means allow to login) while login.
I think I need to do some changes in security.yml. I googled about it no idea. I am new to Symfony.
Related
I'm wondering how I can password protect pages (therefore web routes) without any auth. My website doesn't have user login/register system, it's not needed.
All I want is to have a several password protected pages that each have a unique password, these passwords are stored in a database.
How would I go about doing this?
Two steps.
create a page for requesting password, also include which page he is trying to access, if user enters the password correctly, set session variable saying pageX is authenticated and redirect to the page.
Create Middleware that checks for the session variable, if it doesn't exist redirect to password page.
I prefer to combine it with javascript window.prompt and session laravel.
Create a pop up to insert the password of the page.
https://www.w3schools.com/js/js_popup.asp
redirect the result to a route, in the controller search the password form database.
use session from laravel, so if the password exist set the session.
https://laravel.com/docs/5.0/session
4.the session isset is null, redirect it to another route.
I am trying to implement a custom authentication mechanism in Spring.
I have an authentication mechanism, that works like this:
User visits any subpage of my page http://mypage
User gets redirected to http://mypage/login, because my WebSecurityConfigurerAdapter is configured, that any Request (except to /login and /redirect, has to be authenticated)
On the Login page a custom login mechanism happens, where I authenticate the user on an external site, that redirects the user's browser to the external page and then back to another subpage of my page: /redirect with custom data in the response
On /redirect I set the Authentication of the user, depending on the custom data and add a GrantedAuthority ROLE_FIRST
After this step the user is redirected to subpage /home, which is only visible to authenticated users with GrantedAuthority ROLE_FIRST.
If the user clicks on a button on /home a GrantedAuthority ROLE_SECOND is added to the current Authentication of the user and the user is redirected to /secret
The user is then authenticated with two factors (external login, buttonclick) and can see the content of /secret, which requires an authentication with GrantedAuthority ROLE_SECOND
So far so good, but I now want to redirect the user to the initial URL he tried to access. So if the user visited http://mypage/random in the first step, the user should be redirected to /random instead of /secret in the last step.
The problem is, I am loosing the URL in the step with the external login, because there is happening a external redirect and I can't pass the URL to the external service.
How can I manage this?
Bonus Question: What if the URL /random would be the URL to an OAuth2 Token interface instead? Would that change anything?
I'm trying to implement two factor authentication in my Spring application.
Desired situation
I want the user to first log in with his username and password, if those are correct I want the system to generate a random key and email that to the user. After that the system has to redirect the user to a page where he only has to enter the token and login to the system.
What I got so far (in pseudo code)
User enters the login.jsp page. Upon logging in with username/password the system sends out a CustomMade AuthenticationException. In the AuthenticationFailureHandler I do a getAuthentication on the exception (I'm aware of deprecacy) But I use the username to send the user his token. After that I put the exception in the session (using request.getSession().setAttribute ) and finally the system reloads the login.jsp.
Login.jsp sees the exception in the session and shows the token input field. User fills the token input field and logs in. System authenticates the user with the credentials in the session and the given token.
Question
I think it's bad practice to save the username/password in session. Two possible solutions I thought of:
After checking Username/Password. Save the username in a static variable or in DB. When user is entering the token check whether username is in the variable/db and check the token. If the token is correct do a login with the user.
After checking username / password log the user in with a low role. With the low role the user can only go to the token page, after entering a valid token the system gives the user new authorities.
What would be the best solution to implement?
I'm a newb to spring security and I'm not sure where to start. I have requirements to have a multi-page authentication. The first page authenticates the username, if the username exists the web app progresses to the password page. (site image) The second page authenticates the password, if successful then the user is authenticated. I'm not sure how to fit this into spring auth. Do I add multiple login-filters and authenticationproviders ? If I add multiple authenticationproviders, will I be authenticated after the first login ?
Page 1: User enters username. Submit this to your own controller where you check if the user exists. If the user exists, display page 2, pass the username in the model. You better not include Spring Security authentication in this step.
Page 2: User enters password. Use a readonly or hidden field to keep track of the username. Submit the form to Spring Security form login filter. You don't need multiple authentication providers.
Note: This approach has an information "leak"; any visitor can check whether a username exists in the system or not.
It depends on the kind of your authentication:
JDBCAuthentication
You can do with #holmis83 suggests.
LDAPAuthentication:
I am afraid tht you can't do that.
I have a spring controller method which could be called in different scenarios. here is the example...
#RequestMapping("/resetpassword")
public ModelAndView resetpassword( #Valid #ModelAttribute("resetpasswordForm") ResetPawdFormForm resetPawdFormForm, ModelAndView modelAndView){
... this method could be executed in 3 different scenarios....
using the hyper link coming from the user reset password link sent to user email..
eg: localhost/myApp/login/resetpassword//
Here I can authenticate userID and activationSecretCode in DB and let user reset password
user can click on resetpassword link from user settings page.
eg: Since the user is already coming from user settings page, I can validate userSession and allow him to reset password
User can login for first time successfully, but are forced to reset password due to admin requirements for reset initial default password.
eg: in this user neither have session, nor passing any activationcode to validate.
login method validates userid/default password and redirects to resetpassword mapping(method=GET).
How can the system authenticate the user request and allow him to reset password?
One alternative for this is, to use flash attributes and set a authenticationKey as flash attributes...which could be verified in resetpassword method.
is there other way to implement this....
Note: I posted an issue in implementing this approach in
Post: Spring: How to pass Java objects during redirect while using ModelAttribute
Any help?
I think the best way to implement this is using three different action methods:
resetPassword (e-mails)
resetLoggedUserPassword (via settings)
changeDefaultPassword
They may even share the same view, but the behaviors are not equal, so I would avoid overloading the action responsibility.
EDIT: elaborating on your comment:
1) To secure the e-mail link, one way is to add a authentication token. The token can be as weak as a hashed user id plus some salt string, or as strong as a GUID with expiration time in a database table, generated whenever a user requests a password reset.
2) The settings way is not a problem, considering that the user is already logged in.
3) The temporary password action can be secured the same way as 1, or the same way as 2, if you put the user on the session. Logging in the user even with the default password status shouldn't be a concern if the code that verify the status of the account are inside a request filter.