Problem/Motivation

Currently module does not pass tests

Drupal\password_policy\Tests\PasswordPolicyInterface          29 passes  11 fails                 11 messages
Drupal\password_policy\Tests\PasswordManualReset              44 passes                           16 messages
Drupal\password_policy\Tests\PasswordResetBehaviors           57 passes  12 fails                 19 messages

Proposed resolution

Fix PasswordPolicyInterface and PasswordResetBehaviors

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#8 2635986-8.patch2.89 KBdawehner

Comments

andypost created an issue. See original summary.

andypost’s picture

nerdstein’s picture

We can revisit this now that the related issues have been resolved

nerdstein’s picture

Assigned: Unassigned » nerdstein

Getting closer...

Tests to be run:
- Drupal\password_policy\Tests\PasswordManualReset
- Drupal\password_policy\Tests\PasswordPolicyInterface
- Drupal\password_policy\Tests\PasswordResetBehaviors

Test run started:
Thursday, January 14, 2016 - 03:31

Test summary
------------

Drupal\password_policy\Tests\PasswordManualReset 44 passes 16 messages
Drupal\password_policy\Tests\PasswordPolicyInterface 36 passes 14 messages
Drupal\password_policy\Tests\PasswordResetBehaviors 59 passes 3 fails 22 messages
- Found database prefix 'simpletest464831' for test ID 23.

Test run duration: 2 min 36 sec

nerdstein’s picture

The three fails appear to be throwing a false positive due to the reset password redirect:

Pass      Browser    PasswordResetBeha  126 Drupal\password_policy\Tests\Passwo
    GET http://contrib.local/user/login returned 200 (20.25 KB).
Pass      Browser    PasswordResetBeha  126 Drupal\password_policy\Tests\Passwo
    Valid HTML found on "http://contrib.local/user/login"
Fail      Browser    PasswordResetBeha  126 Drupal\password_policy\Tests\Passwo
    GET /user/3/edit returned 0 (0 bytes).
Pass      Other      PasswordResetBeha  129 Drupal\password_policy\Tests\Passwo
    User should be sent to their account form after expiration -- /user/3/edit

Basically, a user with an expired password logs in. The "0 byte" response is a header-based redirect to their edit form, which is the desired behavior. I'm really not sure how to get the error to resolve.

andypost’s picture

The same here, will try to attack at global sprint weekend
Please make alpha-2 release because alpha-1 seriously outdated

nerdstein’s picture

andypost - any update on this? I've been slammed but I was hoping you might have an update from your last comment.

dawehner’s picture

Status: Active » Needs review
StatusFileSize
new2.89 KB

Let's fix it.

[15:14:42] I think I know the reason
[15:14:57] unlike browsers curl/simpletest implements HTTP correctly
[15:15:05] the location header is meant to be an absolute URL
[15:15:12] but well, browsers accept relative ones as well
[15:15:25] that is just a guess, let's see whether the tests pass with it

nerdstein’s picture

Status: Needs review » Reviewed & tested by the community

Patch reviewed, will be committing

dawehner’s picture

+++ b/src/EventSubscriber/PasswordPolicyEventSubscriber.php
@@ -45,7 +45,7 @@ class PasswordPolicyEventSubscriber implements EventSubscriberInterface {
-        $url = $url->toString();
+        $url = $url->setAbsolute(TRUE)->toString();

We could have documented what is going on here, to get at least some frustration out there.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 8: 2635986-8.patch, failed testing.

nerdstein’s picture

Status: Needs work » Fixed

Confirmed tests are all passing locally (FINALLY!!!)

Thank you so much dawehner

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.