Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Login with Facebook always uses the port 3000 #1394

Closed
congkinh opened this issue Aug 15, 2015 · 9 comments
Closed

Login with Facebook always uses the port 3000 #1394

congkinh opened this issue Aug 15, 2015 · 9 comments

Comments

@congkinh
Copy link

Hi,

I deployed a version of sharetribe in production mode with integrating Facebook. I use nginx for reverse proxy from 80 (443 later) to 3000. However, when I logged in with my Facebook test account, the redirect_uri was using the port 3000 instead of 80. Could anyone of you tell me how to fix it? The following pattern was received by logging in with Facebook:

:3000/people/auth/facebook/callback?code=

Best regards,
Kinh

@ptzool
Copy link

ptzool commented Aug 15, 2015

Did you change the redirect URL on Facebook developer page? (Valid OAuth redirect URIs)

@congkinh
Copy link
Author

Hi @ptzool,

Yesterday, I let it be empty. I didn't configure anything for this. So, port 3000 was somehow fixed in code itself.

This morning, I just changed Valid OAuth redirect URIs on Facebook with http://example.com/people/auth/facebook/callback (I supposed that mydomain was example.com). However, I still received the redirect_uri with port 3000 from URL. But, it didn't work while I was using this redirect_uri. Facebook said that there was invalid configuration.

@rap1ds
Copy link
Member

rap1ds commented Aug 24, 2015

What's the value for domain in config.yml?

@congkinh
Copy link
Author

Hi @rap1ds,

I used the port 80. I already tested for both domain:80 and domain (without port), the redirect_uri was the same in both cases.

@congkinh
Copy link
Author

congkinh commented Sep 1, 2015

Hi all,

I found out that this issue came from OmniAuth. Actually, I don't know how to solve it in general. But in my case, I just added the following line:

OmniAuth.config.full_host = "https://www." + APP_CONFIG.domain

just after the line 156 in the file https://github.com/sharetribe/sharetribe/blob/master/config/application.rb.

If I were a Rails developer, I would check whether the current URL is using HTTPS or not.

@rap1ds
Copy link
Member

rap1ds commented Sep 4, 2015

Hi @congkinh

This sounds interesting. It could be a bug in our code. However, I would need a little bit more information to debug this further.

Can you provide exact steps how to reproduce the issues? That would be helpful.

You can also use the Issue Template, it's here: https://raw.githubusercontent.com/sharetribe/sharetribe/master/ISSUE_TEMPLATE.md

@congkinh
Copy link
Author

congkinh commented Sep 4, 2015

Hi @rap1ds,

The following information would be helpful for you:

Sharetribe Version:

8fb1611

Environment:

Debian 7 and Amazon S3

Server mode:

Production

Description:

Signing in with Facebook account always redirects to the 3000 port.

Steps To Reproduce:
  • Used a reverse proxy (nginx) to map from HTTPS (outside) to the port 3000 (inside)
  • Created a Facebook application:
    • Activated Web OAuth Login & Client OAuth Login
    • Filled in App Domains
    • Didn't fill in redirect_uri
  • Deployed Sharetribe
  • Signed in with a Facebook account
Expected Result:

I was expected to be able to continue using HTTPS after signing in with a Facebook account.

Actual Result:

The redirect_uri contained the 3000 port. That meant the URL after signing in with a Facebook account contained the port 3000. In other words, it meant I couldn't continue using HTTPS.

Additional information

@rap1ds
Copy link
Member

rap1ds commented Sep 7, 2015

@congkinh Thanks for the information! Right now I don't have time to dig into this issue, but I'll leave the issue open since it looks like something that maybe is a bug (or at least unexpected behaviour) in the code.

@rap1ds
Copy link
Member

rap1ds commented Jan 19, 2016

Closing as inactive

@rap1ds rap1ds closed this as completed Jan 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants