Playframework 安全模块 : how do you "log in" to test a secured controller in a FunctionalTest?

Question

编辑 : 我正在使用 Play!版本 1.2(生产版本)

我想测试由 Secure 模块保护的 Controller 操作
类，所以我需要在测试我的 Controller 之前登录(否则我将被重定向到登录页面)。

我尝试在调用安全操作之前登录。这是我的功能测试的样子:

@Test
public void someTestOfASecuredAction() {
    Map<String, String> loginUserParams = new HashMap<String, String>(); 
    loginUserParams.put("username", "admin"); 
    loginUserParams.put("password", "admin");

    // Login here so the following request will be authenticated:
    Response response = POST("/login", loginUserParams);

    // The following is an action that requires an authenticated user:
    Map<String, String> params;
    params.put("someparam", "somevalue");
    response = POST("/some/secured/action", params);

    assertIsOk(response); // this always fails because it is a 302 redirecting to /login
}

通过代码，我已经验证了登录帖子是否有效 - 它会导致重定向响应，并将位置设置为主页(这表明登录成功)。

但是在随后调用安全操作时，我总是被重定向到
“/login”页面 - 表明我之前的登录没有坚持第二个 POST 请求。

查看 FunctionalTest 的源代码，我看到有一个清除所有 cookie 的 @Before 拦截器。我尝试在我自己的中间父类(super class)中覆盖这个拦截器(以保留 cookie)，但这也不起作用。

编辑 :我将 play.mvc.Before 拦截器与 org.junit.Before 混淆了——前者用于 Play! Controller ，后者用于 JUnit 测试。 FuncitonTest 中的 @Before 是一个 JUnit 拦截器，因此它应该对 cookie 有任何影响(因为它在测试运行之前运行一次)。

我不想为每个安全操作编写一个 Selenium 测试——因为几乎所有操作都是安全的。有没有办法让 Secure 模块相信你已经通过了身份验证？或者在功能测试中处理这种(看似常见的)场景的其他一些非常明显的方法？

提前致谢，

标记

编辑 :工作代码，Codemwnci 的答案标记为正确

Codemwnci 的回答是正确的。这是我将cookie从一个请求保留到下一个请求的解决方法:

@Test
public void someTestOfASecuredAction() {
    Map<String, String> loginUserParams = new HashMap<String, String>();
    loginUserParams.put("username", "admin");
    loginUserParams.put("password", "admin");
    Response loginResponse = POST("/login", loginUserParams);

    Request request = newRequest();
    request.cookies = loginResponse.cookies; // this makes the request authenticated
    request.url = "/some/secured/action";
    request.method = "POST";
    request.params.put("someparam", "somevalue");
    Response response = makeRequest(request);
    assertIsOk(response); // Passes!
}

Answer 1

我认为一定对@Before 拦截器的作用存在误解。它在您的测试执行之前执行。如果您的测试随后将您登录，则此事件发生在 @Before 代码执行之后，并且安全模块的结果应保存到 Cookie。

因此，我只能假设 Cookie 没有与以下请求一起发送，因此，我建议尝试以下...

在您登录后立即从 Response 对象获取安全 cookie 使用的 cookie。创建一个请求对象并将 Cookie 设置为请求对象，然后调用您的 POST 方法，传入您的请求对象。

我没有测试过这段代码，所以不确定它对混合预先构建的请求对象和传递 URL 会有什么 react ，但不确定还有什么建议。