How can we have persistent token value(or Form Key) during the valid session in struts2?
When <s:token/> is in the forms, after submitting the form, the token's value gets changed. It causes this problem that users can not open 2 browser tab and work with them(Only one tab is active due to the tokens' unique value per form).
how can I solve this with struts2 and have durable token value per session(Not per form)?
I think overriding the interceptor can solve the problem, but i wanna
to consider other options
Don't use token at all
If you require something per session, use the session itself. Token is meant to prevent request replay attacks. So just having one per session doesn't make sense.
I also had same problem, in my functionality there is preview which opens in new tab. User can preview multiple times, so it was throwing a token exception. I got one code as at start of function I wrote :
String downloadTokenName = TokenHelper.getTokenName();
String downloadToken = TokenHelper.getToken(downloadTokenName);
At end of function in finally I reassign token value as :
TokenHelper.setSessionToken(downloadTokenName, downloadToken);
It solved my problem.
Related
I've got a WebFilter that redirects to the login page in my application. In order to redirect back to the referring page I've also added a view parameter called redirectOnLogin which is then used on successful logins in order to perform the final navigation.
If one were to manipulate this query parameter, one could easily provoke JSF navigation errors. I would therefore like to pre-empt this by checking that the outcome is valid but I've not been able to uncover a mechanism for pre-validating a JSF outcome.
Easiest and best is to make sure the redirectToLogin parameter cannot be manipulated. Or that manipulation is detected.
You could solve this in (at least) two ways
Taking the original page name, adding a 'salt' to it and creating a hash.
Addin this has that in the request to the login server
Make sure it is returned by the login server (maybe adding it as # to the return page or as a param.
On receiving it on the 'redirectOnLogin' page, use the page name, the same salt and create a hash in the same way. Compare these and if they match you are fine, if they don't throw an error.
Or you could
Store the 'redirectOnLogin' page in a session to
Check on returning from the login server if it matches with the page you end-up on.
What would be the best approach for a Play! application to remember the user? I think the only possible solution is to use the client side cookies, right? But as soon as the browser shuts down, this session is destroyed and not valid for the next request? How did/do you solve(d) this?
As for now, I ser the crypted userid in the session (per session), like this:
session("userid", user.id);
And then I use the interceptor to avoid passing parameters every when I need them oft, like described here: How to avoid passing parameters everywhere in play2?
But how to remember the user, or even beter, automatically log the user in on the next request?
EDIT: 2016-03-11
Be aware that some browser may store the session cookie for a longer period. For instance you can set in Chrome to remember the open tabs on next visit. This means that the Play Session cookie will be restored next time you open the browser.
And as of Play 2.4 the session cookie maxAge (you need to set in the application.conf) is renamed to: play.http.session.maxAge
To make the session not time-out when a users closes their browser you can use the session.maxAge parameter in the application.conf.
e.g.:
# Set session maximum age in seconds (4w)
session.maxAge=2419200
Quoting from Play 2.0 Session Documentation:
There is no technical timeout for the Session. It expires when the user closes the web browser. If you need a functional timeout for a specific application, just store a timestamp into the user Session and use it however your application needs (e.g. for a maximum session duration, maxmimum inactivity duration, etc.).
For security reasons, modern browsers will invalidate cookies on exit, and this is not something you can change simply because it would allow hackers to bad things with credentials that they do not rightfully have.
I would reevalutate whether or not you truly want the user to stay logged in, since it is usually a security risk to do so. If, however, you decide that you still want the user to stay logged in, you will have to try something that is not cookie based, and at the moment, I'm not sure what that would look like.
If you don't force a newSession or the user doesn't remove the cookies, the user should still be logged in.
It may be that your browser is set up to remove cookies when closing, or you are suffering from an external sideeffect. But I can confirm that cookies persist in my dev environment (in both Chrome and Firefox) after closing the browser.
I tried this and it worked for me. It's basically a composed Action.
def RememberAction(f: Request[AnyContent] => Result): Action[AnyContent] = {
Action { request =>
if(!request.session.get("email").isDefined && request.cookies.get("remember-email").isDefined) {
f(request).asInstanceOf[PlainResult].withSession("email" -> request.cookies.get("remember-email").get.value)
} else {
f(request)
}
}
}
Then you can use this Action in your controllers like this:
def index = RememberAction { implicit request =>
Ok("Hello World!")
}
I came across a post on Quora addressing why LinkedIn uses tokens like *1_*1_*1_*1_*1_* in their url. The answer mentioned these help track where a user came from to enable a user to return to where he came from.
How exactly does the URL store that type of information, and why would they use that token instead of something more conventional, such as ?last=this-page?
Appears that those are used to carry forward and populate the form values on the left for the search page. The 1 is probably a section or form number, * means wildcard (empty on form). The _ is just a separator. Try populating a previously empty form field and click search You'll you see one of the previously *1 portions of the url be replace with the value you provided in your form.
I use grails and I have few registration pages.When user enter few textField values, with "Next" link user have to go to the other page....
After user entered all values data have to be saved.
My problem is that I do not know how to take one page's values from another.
What can I use(sessions, setter and getter methods...) to take all entered values in the last page?
I would recommend looking into Grails Web Flow
There are numerous ways to do it
1) Doing a post back, This will send all your form variables as part of HTTP request and you can then query the params to get the values
2) Grails has got a special artifact which is flash. Once you put anything in flash , its remains till the next request
3) You can use session to retain the values till the session does't expire
Hope that help
there is this code below in sfDoctrineGuardPlugin.
$a = sfConfig::get('app_sf_guard_plugin_success_signin_url');
var_dump($a);
$signinUrl = sfConfig::get('app_sf_guard_plugin_success_signin_url', $user->getReferer($request->getReferer()));
var_dump($signinUrl);
var_dump($user->getReferer($request->getReferer()));
It prints this:
null
string
'http://rs3.localhost/frontend_dev.php/'
(length=38)
string
'http://rs3.localhost/frontend_dev.php/miembros' (length=46)
I don't know why the the second and the third lines are different..any idea?
Regards
Javi
Weird. Spooky.
I wonder if maybe the two calls to getReferer() are in different contexts? Maybe the first (as the second arg to sfConfig::get()) implicitly uses __toString() whereas when you use var_dump(), maybe it's printing the raw value of the referer object?
Hrmm... the API says getReferer() returns a string, so that's probably not it.
What are you trying to do, BTW? Is it not honoring your app_sf_guard_plugin_success_signin_url setting from app.yml?
sfDoctrineGuardPlugin sets a referer attribute in the user, so that it can redirect back to the page originally requested. When you call getReferer it removes the attribute. (This is causing bugs for me, which is what brought me here.)
yitznewton pointed me towards a solution. The sfGuardSecurityUser class uses a method setReferer that saves a referer attribute but only if one is not yet set.
If somehow you manage to get to the executeSignin method in the sfGuard actions twice only the first referer attribute will be saved, this means that the second time the referer in the request and the referer in the user attribute can be different.
The getReferer method removes that attribute, and falls back to the request referer when the attribute is not set. this explains why calling $user->getReferer($request->getReferer()) twice returns different values sometimes.
The solution i found was to overwrite the setReferer method of the sfGuardSecurityUser in the myUser class:
public function setReferer($referer) {
$this->setAttribute('referer', $referer);
}
So far i have not found any side effects, this change ensures the user attribute will allways be the most recent, however there has to be a reason to explain why the symfony folk chose to implement this as it was.
Ive tested this by switching between apps on the login screen, allowing the session to die, killing the session manually and normally using the application and so far i have not found any side effects.