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

Expose an API that can disable automatic resume logins #1891

Closed
mizzao opened this issue Mar 5, 2014 · 8 comments
Closed

Expose an API that can disable automatic resume logins #1891

mizzao opened this issue Mar 5, 2014 · 8 comments

Comments

@mizzao
Copy link
Contributor

mizzao commented Mar 5, 2014

It seems that earlier versions of Meteor had a semi-public API for preventing the resume login from being called automatically: https://github.com/possibilities/meteor-disable-auto-login.

This no longer works, because the global enableAutoLogin variable in accounts-base is not exposed in any way. However, this is unfortunate because smart packages may want to disable the resume login in certain cases. In particular, I have a package that authenticates users from Amazon Mechanical Turk (https://github.com/HarvardEconCS/turkserver-meteor) where users have short sessions and should not be able to log in to the app afterward. Before, I just didn't store the resume token for users (#1835), but that no longer seems to work, so I'd like to disable the resume login on the client side when the app is loaded with a specific URL/hash fragment.

In general, it seems like accounts-base should be refactored to not include functions that are specific to accounts-password (https://github.com/meteor/meteor/blob/devel/packages/accounts-base/url_client.js). This would also allow other packages that deal with accounts to disable the resume login in certain cases.

Possibly related: #1815, which would allow handling this issue from the server side.

@mizzao
Copy link
Contributor Author

mizzao commented Mar 13, 2014

Going to try handling this from the server side using the newly merged login hooks.

If the other points I raised about accounts-base and accounts-password aren't a concern, feel free to close this issue.

@n1mmy
Copy link
Contributor

n1mmy commented Mar 14, 2014

Yeah, login hooks are a good way to go about this.

Maybe in the future we will rework the accounts apis to allow more options around this sort of thing. Hopefully login hooks suffice for now.

@n1mmy n1mmy closed this as completed Mar 14, 2014
@lorensr
Copy link
Contributor

lorensr commented Feb 29, 2016

[deleted: incorrect comment referring to outdated article https://meteorhacks.com/extending-meteor-accounts/]

@mizzao
Copy link
Contributor Author

mizzao commented Feb 29, 2016

@lorensr that's interesting - I don't think that was always the case. Do you know off the top of your head which version of Meteor this started in?

@lorensr
Copy link
Contributor

lorensr commented Feb 29, 2016

Oops, I'm sorry – article was written a while ago. The repo uses Meteor 0.6.3.1. From the comments, it looks like that was before the point at which resume tokens started being created automatically. I assume they still are. What's the way you used with login hooks to login without resume tokens?

@mizzao
Copy link
Contributor Author

mizzao commented Feb 29, 2016

I'm not sure it's possible; I just added logic to pull login tokens on certain disconnect/logout events.

@lorensr
Copy link
Contributor

lorensr commented Feb 29, 2016

I see, thanks. My use case is an OTP link giving restricted access to your account for the duration of your session. I don't want to remove all login tokens (which would log them out of their full-access browsers) – just the one created during restricted login. I guess I can do a setTimeout at the end of the registerLoginHandler that removes all resume.loginTokens with a recent when (will usually just be one such).

@lorensr
Copy link
Contributor

lorensr commented Mar 3, 2016

This works as a connection-specific login:

// client
Meteor.call('connectionLogin', function(e,r) {
  if (!e)
    Meteor.connection.setUserId(userId)
})

// server
Meteor.methods({
  connectionLogin: function() {
    this.setUserId(userId)
  }
})  

Are there any downsides to doing it this way, other than having to configure your own rate limiting?

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