CODEWITHSUNDEEP
playframework-1.x
LamLe
LamLe

Reputation: 45

Play framework 1.2.5 - Secure redirect issue : request two time?

I've added Secure module in my project..
I debuged and found that Secure module always redirect to url="/" after login success

Example, in Secure class

public class Secure extends Controller {
@Before(unless={"login", "authenticate", "logout"})
 static void checkAccess() throws Throwable {
 // ... default code
 // ---------------------------checkpoint (2)
}

static void redirectToOriginalURL() throws Throwable {
        Security.invoke("onAuthenticated");
        String url = flash.get("url");
        if(url == null) {
            url = Play.ctxPath + "/";
        }
        System.out.println("DEBUG: redirectToOriginalURL() " + url);
        redirect("/weekPlan"); // ----------------------- (1)
    }
}

debug order

  1. After login success, redirectToOriginalURL() run first, then redirect to "/weekPlan"

  2. checkAccess() run, request.path="/weekPlan"

  3. Everything run normal but it doesnt redirect to "/weekPlan"

  4. checkAccess() run again, and request.path="/" ????

I dont know why they run two time and the second time, request.path="/" ?

Thanks much, Lam

Upvotes: 0

Views: 301

Answers (1)

gpgekko
gpgekko

Reputation: 3616

The second time, url will be null because the flash context gets cleared, it doesn't retain its values for more than one subsequent request unless explicitly told to, that is it's default behavior.

The reason it hits checkAccess twice is not within the code you have posted, so I can't comment on that. I can say that you're mixing up the flow. The order in which events will occur with the default Secure code is as follows:

  1. Url request, checkAccess gets fired.
  2. checkAccess denies access by redirecting to the login page, putting the current request url in flash scope.
  3. login and authenticate do their thing (the actual logging in), then at the end of authenticate it calls redirectToOriginalURL.
  4. redirectToOriginalURL sends a redirect to the browser, browser makes request.
  5. Url request, checkAccess gets fired.
  6. checkAccess confirms that this time we are authenticated and therefor takes no action, allowing the controller method to start doing its thing and return the normal results.

Therefor, step 3 and 4 in your question can't possibly be the Secure models fault (at least, with the default code). You'll have to inspect the rest of your code to find the source of this behavior.

Upvotes: 4

Related Questions