I'm working on a wicket legacy-project and i'm trying to fix a bug with the session time-out.
Basically I'd like to have a redirect to a customed error page after session times out.
This is what I did:
web.xml :
<session-config>
<session-timeout>1</session-timeout>
</session-config>
in the application class:
#Override
public void init() {
super.init();
getApplicationSettings().setPageExpiredErrorPage(ErrorMessagePage.class);
This is not working. I mean after session time out, nothing happens.
What am I doing wrong?
EDIT 04.05.20
Based on the feedback from Martin I tried to implement a session validaty checker:
public class SessionValidityChecker implements IRequestCycleListener {
#Override
public void onBeginRequest(RequestCycle cycle) {
HttpServletRequest request = (HttpServletRequest) cycle.getRequest().getContainerRequest();
boolean sessionValid = request.isRequestedSessionIdValid();
if (!sessionValid) {
cycle.setResponsePage(SessionExpiredPage.class);
}
}
}
and in Application.class
public void init() {
super.init();
getRequestCycleListeners().add(new SessionValidityChecker());
}
Also what I may should have specified in my first post is that I use the wicket SignInPanel for authentification. After timeout, I'd like the user to be logged out and redirected to a specific page.
This is what I've tried with the above code, but after session time out, no redirect happens. Even worst, the user is still signed in. What am I missing?
You are mistaking page expiration with session expiration.
Stateful pages are stored in a PageStore (disk) and the store may grow up to some predefined size. Once this size is reached the oldest page is removed to make room for the newest one.
If your user uses the browser Back button many times at some point Wicket will throw PageExpiredException for the deleted page.
In your case when the session expires usually the web server (e.g. Tomcat) will just create a new one. If your application has authentication enabled then it will detect that there is no authenticated user in the new http session and most probably will redirect the user to the login page.
If there is no authentication in place then Wicket will create a new instance of the requested page and render it. You can change this by changing PageSettings#recreateBookmarkablePagesAfterExpiry to false
(see https://github.com/apache/wicket/blob/79f63f66eb588a5d69e9feff7066f1244f61f387/wicket-core/src/main/java/org/apache/wicket/settings/PageSettings.java#L46)
You may use javax/servlet/http/HttpServletRequest.html#isRequestedSessionIdValid() method to find whether the the request came with an expired JSESSIONID cookie/url. If it is false then the web server just created a new HttpSession. You can do the check in Wicket's IRequestCycleListener#onBeginRequest()
Related
I'm using Activity/Place in my GWT project, if current user is not logged in, when he navigates to some Place, the user will be redirect to login page, if the user has logged in, then he will be taken to that Place. How to implement this logic efficiently?
I tried to hook PlaceChangeRequestEvent:
eventBus.addHandler(PlaceChangeRequestEvent.TYPE,new PlaceChangeRequestEvent.Handler() {
#Override
public void onPlaceChangeRequest(PlaceChangeRequestEvent event) {
Place newPlace = event.getNewPlace();
if (newPlace instanceof MyProtectedPlace && userNotLoggedIn()) {
event.goTo(new LoginPlace());
}
}
});
Unfortunately it does not work since the ongoing request for MyProtectedPlace is not cancelled.
Yes I could check this when user are about to navigation away from current place, but this will not be efficient as the check logic will scattered throughout the program.
Thanks.
You can do it a little bit differently I think. Let's say that you want a place called SecuredPlace to be accessible only after login. You have a corresponding SecuredActivity.
What you can do is, when you start your SecuredActivity, you check if your user is logged in. If not you do placeController.goTo(new LoginPlace ()).
If the user is logged in then you continue. As the start is called by the framework there is no way to skip this step which in my opinion makes it secured enough.
But you should implement your security on network calls to your backend not on places. Every time you call the backend, you check that user is authenticated and has the right credentials. If not you can intercept the callback, check that it is a 403 error and then redirect automatically to your login page. Because if your backend calls are not secured, securing your places is useless.
I am using Liferay 6.1 version .
Once a User enters http:localhost , i am displaying my Web Page called "/ravi" which consists of my Custom Portal as shown
I have configured this below properties under portal-ext.properties as shown
auth.forward.by.last.path=true
default.landing.page.path=/web/guest/ravi
Please see the screen shot of my Custom Portlet shown when the users enters http:localhost
Now my requirement is that i need to show another page ("/web/guest/test") if he enters valid crendentails .
In my processAction class , i am doing this way
public class ValidateUser extends MVCPortlet {
public void processAction(ActionRequest request, ActionResponse response) {
String userName = (String) request.getParameter("userName");
String password = (String) request.getParameter("password");
try {
// Contatcs DB and validates the credentials here
// Please let me know how can i show the Configured Page if his credentials are valid ??
}
catch (Exception e) {
}
}
}
Edited Part
Thank you very much for the answer with respect to the default login.events.post .
I am new to Liferay , so i may be doing a mistake here , so please help me if i was doing anything wrong .
I followed these steps :
Created a New Portlet named "MyLogon" Portlet and in its view.jsp created a form with two text fields (Login and Password ) and a submit button .
On click of that Submit Button , i was actually calling my processAction Method and making a DB call to validate Users from mysql db .
2.Then i created a page inside /web/guest/ravi and added this "MyLogon" Portlet to this new page /web/guest/ravi
Then configured this below properties under portal-ext.properties
auth.forward.by.last.path=true
default.landing.page.path=/web/guest/ravi
This is what i did .
And when entering http:localhost:8080 , it displayed taht page .
Please tell me if i am doing anything wrong
Edited 2nd Part
I have understood some part of your answer and i have these questions .
Could you please help
I need to validate Users based on the Data present inside my DataBase , so for this i need to do the below thins .
I need to create a Hook , to overdide this property
login.events.pre=com.LoginAction
public class LoginAction extends Action {
public void run(HttpServletRequest req, HttpServletResponse res) {
// Here i need to make a Database call to validate User Credentials and then do redirect him to the page i wanted ??
}
}
You need to create a Hook and override the default login.events.post
Below code for your reference,
public class LandingPageAction extends Action {
public LandingPageAction()
{
}
public void run(HttpServletRequest request, HttpServletResponse response) throws ActionException
{
try
{
doRun(request, response);
}
catch(Exception e)
{
throw new ActionException(e);
}
}
protected void doRun(HttpServletRequest request, HttpServletResponse response) throws Exception
{
String homeRedirect="/web/guest/test";
LastPath lastPath = new LastPath(StringPool.BLANK, homeRedirect);
session.setAttribute("LAST_PATH", lastPath);
}
}
There are few things which I don't understand here. You are hitting localhost:8080, but screen shot shows that you are already logged in (there is a SignOut link and user Ravi Kiran is already logged in), but still there is a login page shown.
default.landing.page.path comes into picture when you are loggedin user. Are you hitting localhost:8080 or localhost/web/guest/Ravi ? You are not logged in yet, so it should not redirect to /web/guest/Ravi.
You could reuse the default Authentication code in Liferay. Not sure why you are taking User credentials from request parameters and making DB call yourself.
Edited as per the update in the question
1. The default Login Page of Liferay (the one that you see when you freshly download and hit localhost:8080 comes from this path
..\default\deploy\ROOT.war\html\portlet\login.
There is a login.jsp in this path which you can edit and give your own look and feel.
You can find below entry in this login.jsp page
<portlet:param name="struts_action" value="/login/login" />
This has a corresponding entry in ../deploy/ROOT.war/WEB-INF/struts-config.xml
<action path="/login/login" type="com.liferay.portlet.login.action.LoginAction">
<forward name="portlet.login.login" path="portlet.login.login" />
</action>
You can open up the source code and look into com.liferay.portlet.login.action.LoginAction method.
This performs a basic Authentication as per your passwords.encryption.algorithm= and passwords.digest.encoding=
configuration in portal-ext.properties file. LoginAction will perform basic authentication and will redirect all
users as per path mentioned in default.landing.page.path=
If you want (some) Users to redirect to (some) other path(conditionally), you can use the code I have mentioned above by writing a Hook.
2. Once authenticated, you can login and create a Page (in your case its "ravi"). You can add your custom Portlet to this Page. You should not write a cutom portlet which will do authentication once you are already logged in
Okay, if cookies are a no-no, then I need a little guidance as to the best way to implement the application(s) that I'm creating.
The scenario is that I'm trying to create a single Asp.Net MVC application that can authenticate a user regardless of whether the user visits a site directly or via an iFrame in Facebook. There are separate actions (in separate controllers, actually) for getting INTO the app depending on whether the user enters via Facebook or not, but there are also places in the Facebook app where I'm opening up a new window to "extended" functionality in other areas of the application that can't really work well within the iFrame. It is supposed to transition seamlessly. It's currently working quite well using cookies, but I've from multiple sources that this is not a good thing for iFrame apps. However, I'm not sure exactly what this means.
Without cookies, can you still somehow get server-side access to the authentication token? If not, then what is the "right" way to handle this. Do I need to resort to manually parsing the token using the JS API and sending an AJAX notification to the server of the fact that the user is authenticated and create a forms auth token? Will the CanvasAuthorize attribute work without cookies? Right now I have added code to the FormsAuthentication_OnAuthenticate event in Global.asax to create the forms auth token if the user is logged in via Facebook (and properly associated with a valid user in the external app) as follows:
protected void FormsAuthentication_OnAuthenticate(Object sender, FormsAuthenticationEventArgs args)
{
if (FormsAuthentication.CookiesSupported)
{
if (Request.Cookies[FormsAuthentication.FormsCookieName] == null)
{
// Attempt to authenticate using Facebook
try
{
FacebookApp fbApp = new FacebookApp();
if (fbApp.Session != null)
{
dynamic me = fbApp.Get("me");
String fbID = "" + me.id;
MembershipUser mUser = AppMembershipProvider.GetUserByFacebookID(fbID);
if (mUser != null)
{
FormsAuthentication.SetAuthCookie(mUser.UserName, false);
AppMembershipProvider.UpdateLastLogin(mUser.UserName);
Session["FacebookLogin"] = true;
}
}
}
catch (Exception e)
{
Elmah.ErrorSignal.FromCurrentContext().Raise(e);
}
}
}
else
{
throw new HttpException("Cookieless Forms Authentication is not " +
"supported for this application.");
}
}
Will I need to change this?
Sorry if this is basic knowledge, but I'm confused as to how best to implement this. Thanks!
First, let me address the issue with the cookies. So, when I say to not use cookies in iFrames I am saying that for a couple reasons. First in IE, there are some security issues. You need to add the following header to your app to make cookies work correctly inside iframes:
P3P: CP="CAO PSA OUR"
The second big issue with cookies in iframe apps is Safari. Due to security settings in Safari, cookies cannot be created by iframes. As such, you will not be able to rely on cookies for authentication inside of iframes.
Give that you are using the app inside and outside of the iframe, you should have cookie support turned on. However, your app must be designed in a way that will work around the iframe issues. That is going to be the hard part.
The most reliable authentication inside iframe apps is the signed request method. What happens is facebook will append a query parameter to your url when the url is rendered inside the iframe. This query parameter contains the user's session. The Facebook C# SDK handles reading this for you, so you dont need to parse it etc. But you need to be aware that it is there. If you view the incoming request url of your iframe app in facebook you will see something like http://www.mysite.com/page/?signed_request={blahblahblah}.
So the key is that you need to make sure that if you are in the iframe you keep that ?signed_request value on the url.
You can do this several ways. First, you can use the CanvasRedirect methods. These are extension methods on System.Web.Mvc.Controller in the Facebook.Web.Mvc namespace. The canvas redirect uses javascript to redirect your page in the top url. This way Facebook is actually handling the redirects and will always add the signed_request to your iframe url. The problem for you is that this method of redirecting will only work in the iframe, not outside.
The second way would be to manually add the ?signed_request to the url when you redirect. You would do something like:
public ActionResult Something() {
return RedirectToAction("something", new { signed_request = Request.Querystring["signed_requets"]);
}
There are other ways also, like storing data in the session or something, but I wouldn't recommend going down that path.
What you are doing is definitely an advanced senario, but hopefully the above will help you get going in the right direction. Feel free to contact me directly if you have any questions. nathan#ntotten.com or #ntotten on twitter.
I am in a similar situation to you. What I do to handle the various situations that can arise is:
Enable cookies in both the C# and
JavaScript SDK.
Create a custom actionfilter that
inherits from
FacebookAuthorizeAttribute and
overrides the
HandleUnauthorizedRequest method to
redirect to either a connect
authorization page or an action
decorated with the
CanvasAuthorizeAttribute.
Pass either the signed_request
(canvas app) or auth_token (connect
app) as a querystring parameter to
everything.
Check for null sessions and oauth
tokens that don't match what has been
passed in the querystring.
The main point is to ensure that both the session and oauth tokens are valid. When inside Facebook the signed_request will ensure this is true. By passing the token from your connect auth page you can ensure you have a valid token to inject into the FacebookApp constructor.
public class FbAuthenticateAttribute : FacebookAuthorizeAttribute
{
private FacebookApp _fbApp;
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
base.OnActionExecuting(filterContext);
var accessToken = filterContext.HttpContext.Request.Params["access_token"];
if (FacebookApp.AccessToken != accessToken && !string.IsNullOrEmpty(accessToken))
{
_fbApp = new FacebookApp(accessToken);
}
else
{
_fbApp = FacebookApp;
}
filterContext.Controller.ViewBag.Context = GetContext().ToString();
filterContext.RequestContext.HttpContext.Response.AppendHeader("p3p", "CP=\"CAO PSA OUR\"");
try
{
dynamic user = _fbApp.Get("me");
var signedRequest = filterContext.HttpContext.Request.Params["signed_request"];
filterContext.Controller.ViewBag.QueryString = string.IsNullOrEmpty(signedRequest)
? "?access_token=" + _fbApp.AccessToken
: "?signed_request=" + signedRequest;
}
catch (Exception ex)
{
string url = GetRedirectUrl(filterContext);
filterContext.Result = new RedirectResult(url);
}
}
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
string url = GetRedirectUrl(filterContext);
filterContext.Result = new RedirectResult(url);
}
private string GetRedirectUrl(ControllerContext filterContext)
{
return new UrlHelper(filterContext.RequestContext).Action(GetRedirectAction(GetContext()), "Authentication");
}
private Enums.AppContext GetContext()
{
//Note: can't rely on this alone - find something more robust
return FacebookApp.SignedRequest == null ? Enums.AppContext.FBWeb : Enums.AppContext.FBApp;
}
private string GetRedirectAction(Enums.AppContext context)
{
return context == Enums.AppContext.FBWeb ? "ConnectAuthenticate" : "Authenticate";
}
}
It could definitely do with a refactor and still has problems but is the best solution I have found so far.
I am developing a web application using GXT, Hibernate, mysql etc. There is a login page for the application. Actually I am getting problem to set the login page when the session expires. We can set the timeout in the web.xml file but in that case we can't redirect to login page.Can you tell me how to achieve that.
You can not do a server side redirect because the application is entirely AJAX. What you can do is use the GWT Timer class and for every one of your RPC calls check/reset the timer. If the "session" expires then you do a redirect to the login page via a History token. This was the easiest way for me
Some other reading:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/b9eab8daaa993c83/d0192d356045e061?pli=1
http://gwt-ext.com/forum/viewtopic.php?f=9&t=1682
I have used the concept of throwing an exception in the server side when the session expires and then tried to catch the exception in the client side. I don't know whether there is any better way to do that.
On the server side, you can check if the session is expired and if so, throw a custom exception.
On the client side, on every async call you do a check for this known situation and react to it. You can create an abstract class for AsyncCallback that you will subclass for each GWT RPC call:
public abstract class SessionExpiredAwareAsyncCallback<T> implements AsyncCallback<T> {
#Override
public void onSuccess(T returnObject) {
doOnSuccess(returnObject);
}
#Override
public void onFailure(Throwable exception) {
if (exception instanceof SessionExpiredException) {
goToLoginPage();
} else {
doOnFailure(exception);
}
}
public abstract doOnSuccess(T returnObject);
public abstract doOnFailure(Throwable exception);
}
You can use gwteventservice to fire an event from the server to the client.
Now on unauthorized attempt to access an action my ASP.NET MVC app redirects user to the login page and generates URL shown below:
http://www.mysite.com/Account/Log?ReturnUrl=%2Ftest%2Fsampleaction
So, is there a way to eliminate this string from the URL, but to save it somewhere to be able to redirect user back after login?
I wonder why you would want to do that. Maybe you are sick of misused, excessive URL parameter orgies, and you like the clean RESTful URL style and the elegant way it can be implemented using the new ASP.NET Routing feature.
However, in this case, this is exactly what URL parameters are intended for. It's not bad practice or bad style at all. And there is absolutely no reason to apply SEO witchery to your login page. So why should you make this process less reliable for the user by requiring the session state directly (or indirectly via TempData), or any other workaround?
I would consider to implement my own AuthorizationFilter and do the redirect.
public class AuthorizationFilter : IFilter
{
public bool Perform(ExecuteWhen exec, IEngineContext context,
IController controller, IControllerContext controllerContext)
{
if (context.CurrentUser.IsInRole("Administrator"))
{
return true;
}
context.Response.Redirect("home", "index");
return false;
}
}
Before redirecting to login action store url
TempData["redirect-url"] = "/requested/page/url";
on login action read that value and pass it to login view and put to a hidden field.
I would implement a AuthorizationAttribute
public class MyAuthorizeAttribute : AuthorizeAttribute
{
public override void OnAuthorization(AuthorizationContext filterContext)
{
base.OnAuthorization(filterContext);
if (filterContext.Result is HttpUnauthorizedResult)
{
filterContext.HttpContext.Session["ReturnUrl"] = filterContext.HttpContext.Request.UrlReferrer.AbsoluteUri
filterContext.Result = // Your login page controller;
}
}
}
This is not tested but might help you find the answer
Good luck to you, please provide your solution when found.