Twitter force_login and Facebook authType not working? #7584
Comments
* Google supports many * Facebook supports `auth_type` * Twitter supports `force_login` API URLs included for reference. Related to meteor/meteor#7584 meteor/meteor#7078 and meteor/meteor#7820
According to the Facebook docs: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow The parameter should be `auth_type`, not `authType`. A cursory look through their API history didn't show anything about it being changed, but I can confirm that using this feature does not work with `authType` in the current implementation. Related meteor/docs#94 Related meteor#7584 Closes meteor#7078
abernix
added
confirmed
|
Thanks for opening this issue. For Facebook's As far as Twitter: Yeah, the implementation of |
According to the Facebook docs: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow The parameter should be `auth_type`, not `authType`. A cursory look through their API history didn't show anything about it being changed, but I can confirm that using this feature does not work with `authType` in the current implementation. Related meteor/docs#94 Related #7584 Closes #7078
Using a the previously-supported ability to pass a function (versus a string) for an oAuth1 URL, this commit implements (and relocates) a function which safely applies whitelisted params to that URL. This introduces a twitter_common.js file shared between server and client which indicates which Twitter-supported params are permitted on the authorize step. The two params which Twitter supports right now are `force_login` and `screen_name`. (See: https://dev.twitter.com/oauth/reference/get/oauth/authenticate) This commit removes the non-functional implementation of `force_login` introduced by meteor#6987 and implements it via the aforementioned method. As a precaution (and since neither `ecmascript` nor `es5-shim` are used by this package), I stuck with JS ES3. Closes meteor#7584
Using a the previously-supported ability to pass a function (versus a string) for an oAuth1 URL, this commit implements (and relocates) a function which safely applies whitelisted params to that URL. This introduces a twitter_common.js file shared between server and client which indicates which Twitter-supported params are permitted on the authorize step. The two params which Twitter supports right now are `force_login` and `screen_name`. (See: https://dev.twitter.com/oauth/reference/get/oauth/authenticate) This commit removes the non-functional implementation of `force_login` introduced by #6987 and implements it via the aforementioned method. As a precaution (and since neither `ecmascript` nor `es5-shim` are used by this package), I stuck with JS ES3. Closes #7584
|
@MichaelJCole Again, thanks for reporting this. This should be fixed in the release candidate right now (specifically, I tested it with your reproduction, and it did in-fact work. I did run into a bit of a problem getting the Please report back if you still have problems with this! |
|
Right on, thanks! |
* Google supports many * Facebook supports `auth_type` * Twitter supports `force_login` API URLs included for reference. Related to meteor/meteor#7584 meteor/meteor#7078 and meteor/meteor#7820
This is about OAuth logins, via these commits
Twitter offers a force_login parameter to ask the user to re-enter their password. This is useful for selecting a twitter account in the case someone has more than one account. It's coded in Meteor here
Facebook offers a similar feature through auth_type which seems to be encoded in Meteor as authType
I'm using the meteor-link-accounts package but neither request seems to be adding these parameters to the URL. (The link shows the code that calls into Meteor Framework).
Is there an example for this?
Here's a reproduction.
The expected behavior is that force_login is passed to twitter, but that doesn't appear to be happening.
The text was updated successfully, but these errors were encountered: