Password Reset Implementation

[evbots]

Having some trouble implementing the password reset. My form for the password reset form mirrors your example code. My event listener looks like...

$rootScope.$on('auth:password-reset-prompt', function() {
    console.log('reset password');
    $state.go('password-reset');
  });

That message isn't logged out to the console. The password reset state is set up properly in my routes. Looking at my server output, the parameters associated with the /auth/password POST request look like this...

Started POST "/auth/password" for 127.0.0.1 at 2014-07-18 10:39:51 -0400
Processing by DeviseTokenAuth::PasswordsController#create as HTML
  Parameters: {
"email"=>"test@aol.com", "redirect_url"=>"http://localhost:9000/?client_id=Nn6qRzJAsfMBF7XZgwjh_g&expiry=1406903819&reset_password=true&token=J3SWEcdBFCbI6ibRLBIDcQ&uid=test%40aol.com#/login", 
"password"=>{"email"=>"test@aol.com", "redirect_url"=>"http://localhost:9000/?client_id=Nn6qRzJAsfMBF7XZgwjh_g&expiry=1406903819&reset_password=true&token=J3SWEcdBFCbI6ibRLBIDcQ&uid=test%40aol.com#/login"}}
Can't verify CSRF token authenticity
Unpermitted parameters: password
Unpermitted parameters: password
Unpermitted parameters: password

As you can see, the params are getting passed in a second time under the password key. All my modules seem to be up to date. Any reason why password is included as a param? To clarify: The reset email is sending, but the event doesn't fire.

[lynndylanhurley]

I'll look into this right away.

[lynndylanhurley]

Can you post the code that you're using to send the password reset request?

[lynndylanhurley]

Ahh I see - it's trying to process the request as HTML:

Processing by DeviseTokenAuth::PasswordsController#create as HTML

It's rendering the default devise HTML form for some reason. Can you please post all the relevant configuration code?

[evbots]

Yeah that's interesting. The code that I'm using to send the password reset request (same as your example configuration to keep things simple):

<form ng-submit="requestPasswordReset(passwordResetForm)" role="form" ng-init="passwordResetForm = {}">
  <div class="form-group">
    <label>email</label>
    <input type="email" name="email" ng-model="passwordResetForm.email" required="required" class="form-control"/>
  </div>
  <button type="submit" class="btn btn-primary btn-lg">Request password reset</button>
</form>

I reconfigured my environment to make sure I wasn't forgetting something simple, and kept all the configuration at the defaults. Not using the omniauth addon right now. It seems unrelated, but I configured CSRF protection per this SO post: http://stackoverflow.com/questions/7600347/rails-api-design-without-disabling-csrf-protection

[evbots]

If i'm omitting some angular config you want to see, let me know.

[lynndylanhurley]

There are a couple of strange things here:

• why is password being sent as a parameter? this method only accepts email as a param.
• it looks like the password param actually contains an object representing its own parent. That would explain why the server is logging the unpermitted parameters warning three times - once for the object itself, and once for each param.

It looks like the passwordResetForm was modified to include itself somewhere else on the page.

[evbots]

In the process of reconfiguring my front-end environment to sort out this issue, bower install ng-token-auth resulted in:

$ bower install ng-token-auth --save
bower ng-token-auth#*           cached git://github.com/lynndylanhurley/ng-token-auth.git#0.0.16
bower ng-token-auth#*         validate 0.0.16 against git://github.com/lynndylanhurley/ng-token-auth.git#*
bower ng-token-auth#*              new version for git://github.com/lynndylanhurley/ng-token-auth.git#*
bower ng-token-auth#*          resolve git://github.com/lynndylanhurley/ng-token-auth.git#*
bower ng-token-auth#*         download https://github.com/lynndylanhurley/ng-token-auth/archive/v0.1.14.tar.gz
bower ng-token-auth#*          extract archive.tar.gz
bower ng-token-auth#*         mismatch Version declared in the json (0.0.14) is different than the resolved one (0.1.14)
bower ng-token-auth#*         resolved git://github.com/lynndylanhurley/ng-token-auth.git#0.1.14
bower ng-token-auth#~0.1.14    install ng-token-auth#0.1.14

just a heads up

[lynndylanhurley]

Yikes, looks like I pushed a bad tag. Deleting now.

[lynndylanhurley]

It's gone now. Thanks for the heads up.

Also, thanks for bearing with with me thru all of these changes. I hope to release v1.0 within the next few days and things should be relatively stable from then on.

[lynndylanhurley]

I'm worried that this problem may have been caused by versioning issues. Can you please update both the rails gem and this module and see if the problem is solved?

I just added one of those bower version badges to the README, hopefully I'll be less likely to screw up the versioning moving forward:

Also, everything seems to be working on the demo app. It will always run the latest code - if you run into trouble, you can use that app for reference.

[evbots]

I won't be able to verify this for a couple days but i'll check soon thanks lynn.

[evbots]

not sure why, but all my requests are being processed as HTML even after the api and front-end env has been reconfigured. i guess you can close this issue unless someone else can recreate.

[lynndylanhurley]

@evbots - you mentioned that you're using CSRF. Have you tried disabling CSRF?

[evbots]

yes i disabled CSRF as well

[lynndylanhurley]

@evbots - can you try to set the following in config/initializers/devise.rb:

Devise.setup do |config|
  config.navigational_formats = [:"*/*", "*/*", :json]
end

[evbots]

I inspected the request/response headers, they look fine...but the server is still processing as HTML. I added your code to my initializer but the result is the same. My chrome inspect element output is below. What version of ruby are you using in development? I'm thinking it could maybe have something to do with the differences in angular version...you're using angular: "1.3.0-beta.11" and I am using 1.2.16 per the yo scaffold generator. Would you consider being explicit on the which angular version you're currently using on the ng-token-auth readme? I've been reading around and it looks like previous angular upgrades have caused http requests to break due to differences in request headers.

Remote Address:127.0.0.1:3000
Request URL:http://127.0.0.1:3000/auth
Request Method:POST
Status Code:200 OK

Request Headers
POST /auth HTTP/1.1
Host: 127.0.0.1:3000
Connection: keep-alive
Content-Length: 132
Cache-Control: max-age=0
Accept: application/json, text/plain, /
Origin: http://localhost:9000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
If-Modified-Since: 0
Authorization:
Content-Type: application/json;charset=UTF-8
Referer: http://localhost:9000/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Request Payloadview parsed
{"email":"test@aol.com","password":"testtest1","password_confirmation":"testtest1","confirm_success_url":"http://localhost:9000/#/"}

Response Headers
view parsed
HTTP/1.1 200 OK
X-Frame-Options: SAMEORIGIN
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: http://localhost:9000
Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT
Access-Control-Expose-Headers: Authorization
Access-Control-Max-Age: 1728000
Access-Control-Allow-Credentials: true
Vary: Origin
Etag: "209238ba078984566ff92376a4ce0a98"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 9260037a-0d7f-4672-a64e-caeed4a94ba0
X-Runtime: 0.391993
Server: WEBrick/1.3.1 (Ruby/2.1.2/2014-05-08)
Date: Sun, 27 Jul 2014 05:06:31 GMT
Content-Length: 316
Connection: Keep-Alive
Set-Cookie: request_method=POST; path=/

This example is from the registration endpoint, not reset password. Not a big deal because the problem is the same.

[lynndylanhurley]

@evbots - I'll try this out with angular v1.2, but both the request and response headers look fine - I have a feeling the problem is server-side.

I don't think it's the ruby version either. I've tested on each version from 1.9.3 to 2.1.2, and I have travis running tests on both 1.9.3 and 2.1 with each push.

I'm willing to take a look at your code. Can you grant me access to your repo?

[markusklooth]

@evbots - Are you including any other libraries such as http-auth-interceptor that add their own interceptors?

[lynndylanhurley]

@evbots - I'm unable to reproduce this. I'm going to close the issue out - please re-open if the problem persists.