Oauth1 and Ouath2 callbacks after app name change?

[Tom2277]

I apologize if this is really a passport question but I'm asking in case there is something about how the grunt file generates things that might be something I needed to change when I changed my app name and domain name.

My Oauth(s) broke after changing the name of my app and its associated domains.

Is there anything hidden in AFS that would change my callback handling from Facebook and Twitter after I've changed the name of the app?

My domain address appears right - and the request looks like it's going to the right place . Facebook is approving my credentials- it sends a callback
Local auth works.. I can log in fine using the internal name/password interface.

I'm guessing the callback is missing something ? ..

could it be a token or session or app-secret (i might have changed those ?) issue?

here is where the error message comes from in :

//  /node_modules/passport-facebook/node_modules/passport-oauth2/lib/strategy.js

this._oauth2.getOAuthAccessToken(code, params,
      function(err, accessToken, refreshToken, params) {
        if (err) { return self.error(self._createOAuthError('Failed to obtain access token', err)); }

Here is what I see on my server logs:

GET /auth/facebook 302 1ms - 0b
GET /auth/facebook/callback?code=AQAGhundredpluscharacterkeyresponserhereASDFASDF7ASF7ASD7ASF7ADSF87AF98S9F  200 115138ms
InternalOAuthError: Failed to obtain access token
    at Strategy.OAuth2Strategy._createOAuthError (/home/ubuntu/www/node_modules/passport-facebook/node_modules/passport-oauth2/lib/strategy.js:370:17)
    at /home/ubuntu/www/node_modules/passport-facebook/node_modules/passport-oauth2/lib/strategy.js:166:45
    at /home/ubuntu/www/node_modules/passport-facebook/node_modules/passport-oauth2/node_modules/oauth/lib/oauth2.js:177:18
    at ClientRequest.<anonymous> (/home/ubuntu/www/node_modules/passport-facebook/node_modules/passport-oauth2/node_modules/oauth/lib/oauth2.js:148:5)
    at emitOne (events.js:77:13)
    at ClientRequest.emit (events.js:169:7)
    at TLSSocket.socketErrorListener (_http_client.js:256:9)
    at emitOne (events.js:77:13)
    at TLSSocket.emit (events.js:169:7)
    at emitErrorNT (net.js:1253:8)
    at nextTickCallbackWith2Args (node.js:442:9)
    at process._tickCallback (node.js:356:17)

Twitter using Oauth1 gets hung up at the same spot although the logs didn't show the returned key

GET /auth/twitter 200 120031ms
InternalOAuthError: Failed to obtain request token
    at Strategy.OAuthStrategy._createOAuthError (/home/ubuntu/www/node_modules/passport-twitter/node_modules/passport-oauth1/lib/strategy.js:396:17)
    at /home/ubuntu/www/node_modules/passport-twitter/node_modules/passport-oauth1/lib/strategy.js:244:41
    at /home/ubuntu/www/node_modules/passport-twitter/node_modules/passport-oauth1/node_modules/oauth/lib/oauth.js:543:17
    at ClientRequest.<anonymous> (/home/ubuntu/www/node_modules/passport-twitter/node_modules/passport-oauth1/node_modules/oauth/lib/oauth.js:421:9)
    at emitOne (events.js:77:13)
    at ClientRequest.emit (events.js:169:7)
    at TLSSocket.socketErrorListener (_http_client.js:256:9)
    at emitOne (events.js:77:13)
    at TLSSocket.emit (events.js:169:7)
    at emitErrorNT (net.js:1253:8)
    at nextTickCallbackWith2Args (node.js:442:9)
    at process._tickCallback (node.js:356:17)
GET /auth/twitter 200 49541ms

Somehow I'm missing something that used to let the callback work

Again it was all working until I changed the name of my app and changed the domain name.

Thanks for any thoughts people have and sorry if it's inappropriate to ask this sort of question.

Tom

Item	Version
generator-angular-fullstack	x.x.x
Node	x.x.x
npm	x.x.x

Ubuntu 15.10 / etc etc | etc

Item	Answer
Transpiler	Babel / TypeScript
Markup	HTML
CSS	SCSS

ui-router Grunt Client Tests MongoDB Auth | Y etc | etc

[Tom2277]

10 days later. and I'm still floundering .. urgh. I'm not blaming AFS .. but perhaps If I understood how the cookies were being set it wold help. Sorry if this is in the wrong place.

I'm thinking that I'm messing up with

https://github.com/jaredhanson/passport-twitter/issues/12#issuecomment-25642483

If there is no cookie sent during the callback request, that is going to cause the problem (because, naturally, that is where the request token is expected to be when using cookie sessions). Effectively, you're getting a "new" session, which has no knowledge of previously stored values.

Is your callback going to the same domain? Is it using the same protocol? Same port?

I've been working at the domain angle ...experimenting many ways at AWS and with middlware to strip the www ... I'm not sure about the same port

Also, I'm uncertain about how JWT gets involved........

And of course, I am most perplexed that it works on my dev machine not my production environment...but perhaps having the port in localhost:9000 has a sideeffect of keeping cookies uniform ? (sorry if I'm misusing terms.. this is new to me)

[Awk34]

Have you done a full grep for your old app name and made sure you replaced all instances?

Stack Overflow might be a better place to ask if it's not specific to this generator

[Koslun]

Might be a bit late, but did you have any real reason to change your app name? Think it's more likely that changing your app name screwed things up than your domain. Your domain should be pretty separate from the project to begin with. If possible maybe reverse that change and try to just first make your domain name change work?

And of course, I am most perplexed that it works on my dev machine not my production environment...but perhaps having the port in localhost:9000 has a sideeffect of keeping cookies uniform ? (sorry if I'm misusing terms.. this is new to me)

Not sure what you mean but cookies should not be affected by the port change itself. The client application in particular does however change a great deal from development to production environment flags.

I am wondering however if you have verified that you can run the code with the production flag on your dev machine. Only really need to tweak it so that you have the appropriate data for the production version of your database.

Would be good to know the version of your node and npm on both your production and dev machines along with the generator you used to generate your project (check .yo-rc.json in the root of your project folder).

[Tom2277]

Hey Koslun. : )

If I run the app locally using grunt serve:dist that runs it in production right? Doing that the app including the oauth-strategies work fine locally in production(it gives a boot up message saying it is in production)

Name: I will give it a shot to go through and change the name back. On the production server, I did reinstall node and all the modules completely from scratch twice to see if that helped. LOL I probably wouldn't change the name again but it seemed too similar to someone else's commercial trade name.

I am running nodejs - 4.4.3 /npm 2.15.1 in production with nodejs - 4.2.2 / npm 3.4.0 local . (wow , odd that it wouldn't directly install a newer update to npm on my EC2 server?)

The package.json file is of course the same on both machines and the node module versions are identical in a primary way although a number of them loaded slightly more recent versions of the dependencies.

The .yo-rc.json does not show any generator version. I initially generated the project at the end of November 2015.

Thanks for any and all ideas. I 've tried quiet a few things.. most of them 5 times a piece haha.

Today I tried using the passport-google-oauth strategy and I had the same experience that it worked on the local development machine but did not work when pushed to production.

Everything else other than the oauth is working fine on production fwiw.. and like I said the local strategy works both on the live aws server as well as on my mac.

Again I'm really grateful for all I've learned from the generator on top of the ease of it's use.

[Koslun]

The .yo-rc.json does not show any generator version. I initially generated the project at the end of November 2015.

It appears that only newer versions of the generator show the version in .yo-rc.json. Have a look at the top of the grunt file, possibly in the first commit if it's not there now. You should see the version there.

LOL I probably wouldn't change the name again but it seemed too similar to someone else's commercial trade name.

Totally understand that, regret the name of our app but it is essentially just a variable name so I don't think it makes any difference legally or to anyone using the application.

I am running nodejs - 4.4.3 /npm 2.15.1 in production with nodejs - 4.2.2 / npm 3.4.0 local . (wow , odd that it wouldn't directly install a newer update to npm on my EC2 server?)

You still get the 2.x branch of npm every time you install Node 4.x.

If I run the app locally using grunt serve:dist that runs it in production right? Doing that the app including the oauth-strategies work fine locally in production(it gives a boot up message saying it is in production)

Yup, that should run it in production mode. To be completely sure you could also build it locally and start it directly with node, i.e. node dist/server/app.js.

Thanks for any and all ideas. I 've tried quiet a few things.. most of them 5 times a piece haha.

With it working locally but not on your deployment does have me thinking it's something wrong with your deployment itself. Don't know what you've tried or how much you have changed the project since you generated it but I'd go with everything not tracked by version control such as what's in the database and environment variables along with getting your dependencies to the exact same version so that you can rule that out. So on that note I would specifically recommend checking that your server/config/local.env.js files are the same on both your local machine and on the deployment.

[Tom2277]

Fixed the problem - or maybe abandoned the problem by abandoning my old EC2 instance - I ended up launching a new EC2 instance and testing a new AFS project on it. The authentication worked using the amazon server names (i.e. using a domain like ec2-55-555-55-515.compute.amazonaws.com) as app and callback addresses for the facebook and twitter "apps" registered at those companies.

After the test-app worked I tried pushing my existing project to the same new EC2 instance and the my complete project worked there. I'm using the deployment technique in #501 described by mescalito. The passport-facebook and passport-twitter strategies still work with my custom domain names pointed to the projects ip address using AWS route53.

Somehow my original amazon server had something borked on it? Borked in a way that let everything else in my project work other than two Oauth strategies. It is odd because after the facebook and twitter Oauth strategies stopped working 2 weeks ago I tried to clean up the server and npm packages, Twice, even uninstalling all node modules, cleaning npm cache and uninstalling and then reinstalling nodejs completely ( thinking I was starting nearly fresh on the existing server). Well, I don't know anything about systems admin ... know a little bit now after a week of probing around.

I was able to download my mongo db data and upload and mongorestore it onto the running new instance, so it doesn't look like it was a data issue.

ODD: (and I'll update this) - I did not set session secrets and it is still working. I did not set environmental variables to my secret keys yet, but I'll do that now. I did not set my DOMAIN env variable and it works fine without that.. I will not change that for fear of breaking something that might linger even after I change it in my bash_profile. I did set my environment variable NODE_ENV to production.

Thanks for the help guys... sorry to bring you into what wasn't a AFS issue (as you had guessed).

[Awk34]

(closing, but feel free to continue discussion)