I haven't really used it yet, but I was reading the tutorial here and from what I understand of it, once you annotate to it inside your controller, it completely blocks the user off, and only shows the form.
What I wonder is how you would do to simply hide certain parts of the website. Like show a login form on top when the user is not logged in and show a "profile" button when he is logged in. Disable posting abilities when user is not logged in etc. without hiding everything from a guest.
Would you need to create separate views for these situations, or just check inside the view if the user is logged in? And how would you check to see that, using the secure module?
The Play secure module authenticate() stores the 'username' in session upon successful login/authentication.
You can make use of this session property in the view to check if user logged in and then change the track accordingly.
#{if session.username }
<!-- You can show users' profile -->
#{/if}
#{else}
<!-- Show login form now. You can create a login template-tag form and call it here. -->
#{/else}
Related
I am working on a spring mvc web application where user has to log-in to access some confidential data.
So far everything is done but I am stuck at one point.
Consider following scenario:
What is happening Now : User has logged in and has been redirected to HomePage. Now User clicks on address bar and type www.stackoverflow.com and once SO is opened user hits back button of browser, Since User's session is active and hence allowed to access all data.
What Should Happen : When a logged in user goes to another website and then comes back it must login again.
I have done some R&D on handling it with browser history but browser doesn't allow you to play with history.
I have tried handling this in Interceptor.
I have tried using HTTP REFERRER, but It doesn't tell me if User is coming back from another website as browser uses the same request which was used when user redirected after successful login and hence Referrer always returns me Context/login as referrer when user is back from another website.
Now, I am out of ideas, Please guide me to achieve this.
Thanks.
Purpose of such an odd requirement
well user can do whatever he wants to do, what I am trying to do is to make sure that if user forgets to logout and somehow moves to another website within same tab, then his data must be secure enough so that no one can see except himself
There's no way to do this perfectly, considering that the browser's back button isn't in any way different from performing a normal request.
The only remotely feasible way that this could be implemented in a very unreliable and overly complex way would be to add some javascript to every page, and when leaving the page check if the page is one of the bank pages or an external page. Then performing some logout (or store some token to local storage or similar, to indicate that the user has been somewhere else).
Or a better idea would be to talk to the bank people and discuss actual threats and then make sure that the system is designed to withstand OWASP attacks.
Do you have a security consultant or similar person in charge there? Your situation doesn't sound very secure, and I'm surprised you're allowed to work like that, considering how strongly regulated the financial sector is (at least in most of the countries I know).
Options would include:
Keepalive AJAX
Your site could make an AJAX request to keep a very short session timeout alive. For example, session timeout could be 10 seconds and your AJAX request could fire every 5 seconds. These values must be long enough to handle your users with the slowest connections.
Then, if a user navigates to a different site, the session will time out because no AJAX request has been made to keep the session alive.
For this to work best set the following response headers to disable caching:
Cache-Control: private, no-cache, no-store, max-age=0, no-transform
Pragma: no-cache
Expires: 0
Change navigation to POSTs
This is a big job and is best done when designing the site from scratch.
Rather than keep session state within a cookie, you use form POSTs for all site actions, including navigation:
<form method="post" action="/doAction">
<input type="hidden" name="action" value="navigate" />
<input type="hidden" name="params" value="page=aboutUs" />
<input type="hidden" name="token" value="123456789" />
</form>
As you can see there is a token in the form data. Once your form is submitted to navigate to another page, that token value is invalidated server side so it can't be reused. Then if the user clicks back the browser will ask them if they want to resubmit their POST data. Even if they do, as you have invalidated the random single use token on the server, they won't be recognised as being logged in and you can redirect them to the login page to start another session.
Token is a session identifier, however each page load will refresh the identifier and invalidate the old one.
I am running Tomcat 8. Currently I have pages that users always need login to see, and pages that the user never has to login to see. I have both of these cases working.
But now I need to make a page that users SOMETIMES have to login to see (based on the data/configuration of what is being asked for).
Given that, I can't just throw the servlet endpoint in the web.xml web-resource-collection, it wont work that way.
I have tried returning a login view from my servlet, with the standard wiring for j_securtiy_check, but when the service comes back it does not look like the login worked.
To get around my issue, here is what I did.
In my servlet, I grab the data for the object I need to render, if the object states the user needs to be authenticated to view, I check the authentication with request.getRemoteUser().
If no user is found, I redirect to a secure url with a new servlet. The url will have a ?return=myurl in the url. In this case, the login page displays and the new servlet sees the return url and redirects back to the original page.
The original page now does user lookup again, but this time the user is logged in.
This is not the ideal solution, but it does work.
I am using Tuckey URLRewriteFilter. In my application, I have the following pages and button:
Page inside.xhtml which is inside the context of the app: http://example.com/app/inside.xhtml
Page outside.xhtml which is outside the context of the app: http://example.com/outside.xhtml
Page login.xhtml at http://example.com/app/login.xhtml
A login button on outside.xhtml page to go to the login.xhtml page.
Page profile.xhtml at http://example.com/app/profile.xhtml
A logout button on profile.xhtml page to go the inside.xhtml page.
In the umlrewrite.xhtml file, I have the following rule to redirect from inside.xhtml to outside.xhtml:
<rule>
<note>
Requests to /app/inside.xhtml will be redirected to ./../../outside.html
</note>
<from>/app/inside.xhtml</from>
<to type="redirect">./../../outside.html</to>
</rule>
My logic is that after the user log in at login.xhtml page, he will be redirected into the profile.xhtml page. What I expect to happen is the following flow:
Surf to outside.xhtml.
Click login button to go to login.xhtml and log in.
Arrive at profile.xhtml on success login.
Click logout button to go to inside.xhtml.
Get redirected to outside.xhtml.
However, what actually happens is:
Surf to outside.xhtml.
Click login button to go to login.xhtml and log in.
Suddenly get redirected back to outside.xhtml.
Click login button to go to login.xhtml and log in AGAIN (the app didn't record my login).
Arrive at profile.xhtml on success login.
Click logout button to go to inside.xhtml.
Get redirected to outside.xhtml.
The above situation happen repeatedly if I continue to do step 2 after step 7.
Without that <rule>, I always get redirected to profile.xhtml page on success login correctly.
I'd be very grateful if you could give me some advice about this problem.
UPDATE:
In my app, to track the logged in state, I have a #SessionScoped managed bean containing a simple method to record the state:
public void recordUserLoggedIn(HttpServletRequest request) {
HttpSession clientSession = request.getSession();
clientSession.setAttribute("isLogin", true);
}
You do not specify how you are tracking the "logged in" state. Are you using a custom cookie? Relying on the application server's built-in session handling (which is likely also cookie based)?
The most probable cause for your problem is related to how you are tracking the logged in state, and how that state is passed between your various pages & contexts. (Especially when transitioning from logged-in to profile.xhtml.) Keep in mind that cookies can be path based.
To debug your problem:
If you are using a browser, then use firebug/developer-tools and watch the network tab. Especially review the various headers that are being set at each step in your flow.
If not using a browser, then try using a proxy like Charles or Fiddler.
I think by watching the HTTP headers during your flow, the underlying problem will become evident.
I'm new to Stripes and appreciate every hint that brings me nearer to a functioning web-app!
technological setup: java, dynamic web project, stripes, jsp
scenario:
users can login (index.jsp). After correct email-adress and password (LoginFormActionBean.java), the user is forwarded to a welcoming page (loggedin.jsp).
The content on this welcoming page is something like "welcome < username >, you've been successfully logged in!".
implementation:
i have a form in the index.jsp where i take the user input and pass it to a method in the LoginFormActionBean.java --> works!
in the corresponding method i check whether the user is correct and if so, i insert the user in the ActionBeanContext:
getContext.setUser(loggedinUser);
after that i forward to the loggedin.jsp:
return new ForwardResolution("/loggedin.jsp");
the loggedin.jsp contains following important lines:
<jsp:useBean id="loggedinBean" class="mywebapp.controller.LoggedinBean" scope="session" />
...
${loggedinBean.context.user} //show the whole user object
...
<s:form beanclass="mywebapp.controller.LoggedinBean" name="ButtonForm">
<s:submit name="foo" value="PrintUser" />
</s:form>
<s:form beanclass="mywebapp.controller.LoggedinBean" name="TextForm">
<s:text name="user" />
</s:form>
...
the LoggedinBean.java contains a MyActionBeanContext attribute (like the LoginFormActionBean.java).
to get the userobject out of the context i use:
public String getUser(){
return getContext().getUser().toString();
}
furthermore the LoggedinBean.java contains a method, which is annotated with #DefaultHandler and forwards to loggedin.jsp (the same page)
result:
now, what happens is: after logging in correctly, i'm forwarded to the loggedin.jsp,
the line "${loggedinBean.context.user}" is empty and so is the < s:text >-field.
BUT after clicking the "PrintUser" Button, the < s:text >-field in the "TextForm"-form is filled with the user object of the logged in user!
conclusion:
what i think happens, is that the "setContext()" method of the LoggedinBean.java is not called before i manually execute a method in the bean. Because the "setContext()" method in the bean is not called before i press the button!
the online documentation says to use a context attribute in a JSP just write "${actionBean.context.user}". But the context is null!
even the book "pragmatic stripes"(2008) gives no more information about using the ActionBeanContext.
question:
what happens there?
how can i get the "${loggedinBean.context.user}" line to display the logged in user at all?
and how can i get the < s:text >-field to display the user object after loading the JSP, but without pressing the button?
i hope my problem is clear and my remarks are satisfying
I would like to recommend the usage of the MVC pattern. This pattern will lead to an implementation were the Action Beans will act as controllers that handle all http requests and the JSP pages will become passive views with little logic, only accessible via the Action Bean controllers (no direct access to JSP pages any more!).
If you use this pattern, you always have an "actionBean" available in your JPS and thus you can refer to ${actionBean.context} (see: getContext).
I am working with jsp/servlet project and I have to complete the module of access management to my jsps since I have more than one user with different profile.
I defined a table in my database which resume the profil and the url permitted like that:
id_profil :1
url : http://localhost/...xyz.jsp
id page 1
Now I am trying to let the menu modified appropriately to the id_profil of the logged user.
So there are pages allowed in one profile but must be hidden to others.
I have no idea since now how to realize this.
It's kinda a vague exaplanation but you could use an if in your jsp to hide the menu options based on id_profil, something like this:
<c:if test="${currentUser.id_profil == 1}">
<button label="Only id_profil 1"/>
</c:if>
Keep in mind that by changing the values shown by a menu, you aren't preventing a user from accessing a page directly -- even if the user can't get to xyz.jsp by dropping down a menu item, they can still enter xyz.jsp into the address bar of their browser. So you'll have to block the access in another way.
If you have any experience with Spring, or are considering implementing it, take a look at Spring Security. It can be used to limit user access rights to different parts of your application. It isn't terribly hard to implement if you are already familiar with Spring.
ETA: For some basics that don't involve Spring Security, check out security in web.xml: http://java.sun.com/javaee/5/docs/tutorial/doc/bncbe.html#bncbj