I have a web application currently deployed on Wildfly 22, using JSF 2.3 and OpenJDK 11.
I'm currently migrating the login page from j_security_check to a programmatically login, following BalusC example on this post:
Performing user authentication in Java EE / JSF using j_security_check
I'm not posting the login code, because it's exactly like BalusC post.
The login process is working just fine, except when the session-timeout expires on the login page. In other words, when the user requests a protected resource, the login page is presented. If the session expires before the login form is submitted a ViewExpiredException is thrown and an error is presented to the user.
I understand this is the expected behaviour, however it's not the desired situation for the end-user.
I managed to minimize this situation using OmniFaces's ViewExpiredExceptionHandler.
This way, when a ViewExpiredException is thrown, the OmniFaces handler will catch it and redirects to the current URL with the query string.
In other words, the user tries to login after the session expires and the login page is presented again to the user.
I managed to use the #{flash['org.omnifaces.view_expired'] eq true} so that a nice message is presented to the user, explaining that a timeout occurred.
Is there any way to workaround this situation, and performing a successful login even when the session expires, so that the user doesn't have to enter his credentials twice?
Thanks for your help!
Is there any way to workaround this situation, and performing a successful login even when the session expires, so that the user doesn't have to enter his credentials twice?
Yes, by using stateless JSF by setting transient attribute of <f:view> to true.
<f:view transient="true">
<h:form>
...
<h:commandButton ... action="#{requestScopedBean.login}" />
</h:form>
</f:view>
Do note that the backing bean must be #RequestScoped, not #ViewScoped or broader.
See also:
What is the usefulness of statelessness in JSF?
Handle ViewExpiredException in the background and restore form values
JSF without #ViewScoped
Related
I have implemented a login form manually in Twig and I am using the default authentication provided by Symfony 3.4 (based on username and password). Users are stored in a database, therefore I have an Entity which extends AdvancedUserInterface. I am using neither FOSUserBundle nor form builder. Just a simple form. It actually works.
The problem is that I want to integrate Google reCAPTCHA in the login process. I know how to check if the captcha is valid and implemented a custom AuthenticationListener (let's call it MyAuthenticationListener).
I know that Symfony uses UsernamePasswordFormAuthenticationListener as its default listener. The problem is that I could not find a way to change the used listener to that I have implemented.
It seems that in Symfony2 it was as easy as adding the following line in the config.yml:
parameters:
security.authentication.listener.form.class:
MyBundle\EventListener\MyAuthenticationListener
However, I cannot find a way for Symfony3. Any suggestions?
I also tried to find a specific bundle for Symfony3, but I actually could not find anything that is correctly integrated with Symfony Security, allowing me to use the recaptcha in a login form.
Thank you
Your question may be answered here:
https://stackoverflow.com/a/50800993/7408561
The solution is based on a custom-listener triggered by SecurityEvents::INTERACTIVE_LOGIN. That event is fired after verification of credentials but before redirecting to default_target_path defined in security.yml. At this position you can verify the request parameter g-recaptcha-response by calling the google recaptcha api with the corresponding secret.
If the verification fails you can throw an exception and you will be redirected to the login page.
I am encountering a strange situation with MobileFirst 7.1 where users are occasionally unable to authenticate/login. The only indication that something is awry is a message in the console.log
[AUDIT ] CWWKS1100A: Authentication did not succeed for user ID . An invalid user ID or password was specified.
My custom login module uses com.worklight.core.auth.ext.LdapLoginModule (so to clarify I have a login module which authenticates using LDAP). Like I say everything seems to work most of the time but occasionally users end up in a situation where they are unable to authenticate. I suspect that it is probably related to the session in some way, but that is only a guess based on my investigation.
I have added some logging to my 'secret' adapter which prints the session state to the console log, and obviously this appears in the logs just before the failed authentication message above, but it is empty ie. the session contains nothing.The user is obviously trying to access a secure adapter at this point, and because they are not authenticated they end up at the login page (form based authentication I should say also).
Anyway, I noticed that although there appears to be no session data, the jsessionid is there and has not changed i.e. it does not change even if I refresh the browser. This may not be an issue in itself of course, but interestingly if I remove this entry and refresh my browser I am able to login successfully.
I am pretty sure that my handler code calls the relevant success/failure methods in the correct places but of course there is nothing to stop the user refreshing their browser, which causes them to be re-directed to the login page (the app has been developed using AngularJS so is effectively a single-page navigation model).
The only reproducible test I have been able to come up with is when I login to the MobileFirst console and then try to login to our MF 'desktopbrowser' app. I have read that this situation causes a session-related conflict, but as I say the occasional issue I am seeing is not caused by this (though it may be related).
So the problem seems to have been more related to the flow of logic in our application after successfully logging in, than any inherent issue with the MF Platform.
For example when a user refreshes the browser they are effectively still logged in, but because the app (based on logic we have developed) takes the user to the login page on refresh, the user is effectively re-logging in to the same session. If this failed every time it would of course have been easier to pinpoint but it does not. The solution was to force logout on refresh (when the app initialises), thus cleaning up any session data. In future iterations it may of course be better to re-establish the application based on the authenticated session after refresh, but at present that was a step too far.
Another example of this was post login if the subsequent adapter calls failed (e.g. we authenticate and then retrieve profile data from a database), then we were also not logging the successfully authenticated user out.
I'm trying to develop a custom login form using Worklight customSecurityTest, based on SingleStepAuthAdapter application sample.
Basically, I've noticed that the login function used in the SingleStepAuthAdapater is always called after that user try to access to a secured function (after that, on login action, secured data are sent to the user), but if i try to call the submitAuthentication function directly, before any attempt to access to a secured function (i have inverted the "login page" with the "get secured data" page), i got the following error/lo on firebug:
The two POST calls are the same function raised two times by Worklight on login action (submitAuthentication function inside the SingleStepAuthAdapter called by singleStepAuthRealmChallengeHandler.submitAdapterAuthentication(invocationData, {})) and the error is related to the fact that authentication is requested twice: probably when the authentication request is performed, this function is issued twice after that the submitSuccess() function is called inside the handleChallenge (in fact, the issue doesn't occurs when i delete the submitSuccess invokation, but WL framework is not notified and, for example the isUserAuthenticated function return false, until the access to a secured resource is performed).
How can fix this behavior? What are the best practices to develop a simple login-form using worklight that allow authentication before any access to a proteced resource? I have found some workarounds (such as perform a fake data request before perform the submitAuthentication, but i hope that you can suggest me a better solution).
I've consulted the infocenter and the getting started modules, but probably due to my fault I'm not able to found any useful information
A common practice is to have an initial blank page or view for your app.
In WLCommonInit, either access a protected resource (that is what getsecretdata is all about), or call WL.Client.login(). Another option (suggested by #tk27) is to secure the app in the application descriptor and set connect on login to true. This will trigger authentication when the app starts.
Your challenge handler should display a login prompt dialog, and when the authentication successfully completes, transition to the first real page of your app.
This way, authentication is still done in response to a challenge from the WL Server (as it must be) but you don't see anything but a blank page to a login prompt until the login is successful.
i'm implementing a form based authentication for my web application.
i created some users in the JDBCrealm on TomEE server and allow only particular users to access the protected jsf pages.
Now authentication works perfectly and if there is a username password mismatch it is redirected to the error page.
the problem i'm facing here is, if i try to login with the user already available in the JDBCrealm who is not authorised to access the protected the page im getting 403 error.
When I come back and try again get to protected pages i can't again login. Is it because information about my login is remembered in session and I have to invalidate session?
Even if I don't login ?
EDIT:
i ask about at forum: http://openejb.979440.n4.nabble.com/Bug-in-security-TomEE-td4665009.html
and i think its the best answer for my question
instead of trying to implement this yourself take a look to something like spring security, it provides most of the options you will need and if you need to extend it is easy as well
Apache tomcat version: 6.0.20
If user is already logged, and he tries to login again from login page, the j_security_check is not available error is encountered. Is it normal behaviour or I have to do something?
Actually I have different user roles for accessing different pages, and when access to a page is denied to a particular user, I want to redirect him to login page, where he can login with corresponding credentials.
This behavior is normal: the servlet spec only lays-out the procedure for container-managed authentication (i.e. login) when the user requests a protected resource and the user has not already provided credentials. All other scenarios are left undefined, including yours.
If you want to capture "forbidden" conditions, you can use <error-page> mappings in your WEB-INF/web.xml to send the user anywhere you want, including a login page. Just remember that the container will only accept a login after the above conditions are true, so you may have to log the user out first (by terminating the user's session).
What I might recommend is a "forbidden" page that says "You don't have access to this resource. If you'd like to log-in as a different user to access it, please click [HERE]" where [HERE] is a link to a servlet that terminates the user's session and then redirects to the resource the user was trying to access. This will cause the container to request authentication (i.e. present the login form), verify the credentials, and send the user to the desired resource.
If you are using a container (and webapp) along with version 3.0 of the servlet specification, there is a new HttpServletRequest.login() method that can be used to programmatically log a user into your webapp. You might be able to use that instead of terminating the session and doing all those redirects... instead, you could collect the username and password yourself and then ask the container to do the login for you.