I read in the documentation that meteor support user authorizations on database level
how can I use it to prevent users from accessing Html pages when not logged on ?
is it possible ?
thanks
jean-louis
Yes, you can. Meteor 0.5.0 comes with a revised and fully loaded Accounts API. One way to enable access to this set of APIs in your app is to install the accounts-password package.
meteor add accounts-password
Manually create users using Accounts.createUser and log users in using Meteor.loginWithPassword (or one of many external authorization services available). Or just use the accounts-ui feature to handle the authentication stuff automatically using a built-in login UI.
Once authentication part has been implemented, restrict access to your webpage (or parts of it) using a condition like:
if (Meteor.user()) {
// do stuff
}
else {
$('body').html('<div class="error">You must be logged in to use this application!</div>');
}
Related
New Meteor user here. I would like to block former employees from being able to login to a Meteor web app. The login is implemented by the accounts-password package. Does it provide an API to do this easily, if I don't want to delete the users or manually change their password from the database?
I tried to look through Meteor's documentation but found no luck.
You could define a validateLoginAttempt function that checks a custom field in the user document, e.g., disabled, and return false accordingly.
I know how to remove registered users manually via web interface (which is also answered by this question). This can be done without providing user's password.
Is there a way to remove a user automatically without their password? I have only found removeUser API call which requires user's password.
It would help to simplify deployment for testing/stage environments.
There is no API to programmatically access the email/password users in Firebase.
For development purposes, you can delete them through the Login & Auth tab of your app's dashboard.
On my Meteor site, users can log in using an OAuth authentication from a particular provider (vKontakte). After logging in, on a special page of my site users can specify also their email address to receive notifications. Obviously, I want to verify the address before any notification sent.
Standard instructions for email verification that I find in Meteor docs and in other sites use accounts-password package. That's OK, and I can call sendVerificationEmail() from my email update code, but the problem is that accounts-password also adds possibility for local (non-OAuth) registration. My site is rather tightly coupled with the OAuth provider, so I do not want to have any other way to login to my site except via this OAuth provider, and so I do not want to have accounts-password package on my site. Or at least I want accounts-password to have no effect from the user point of view except the possibility to send verification emails (no register buttons etc.)
Is there any way to send verification emails without accounts-password package? Or to disable all accounts-password functionality except email verification?
Of course, I can implement email verification completely manually (generate a token, send an email, setup a route for verification), but if there is some more standard way to do this, I'd better stick to it.
I finally solved this by copying the accounts-password.js file to server/lib and removing all code that I did not need. I do not like this solution because if accounts-password wil be updated, I will have to update my file manually, but I see no other way to do this.
I am not sure that all of what you are describing is needed. Granted, the code would exist on the server, but if you were to add accounts-password and call sendVerificationEmail() there is really nothing to say that you will have to have the signup and password functionality that it allows. Are you using the accounts-ui-unstyled to handle the front end portion of the accounts? If so, you can simply not give the user the ability to see or use the functionality you don't want them to have.
I'd like to use the Meteor.loginWithGoogle() tool to authenticate users, but is there any way to limit it to a specific (Google Apps) domain?
I could check after the user is authenticated using the returned email, but is there a way to do this at the login stage with some parameter for Google login?
I dont think its possible right now.
There is a pull resquest to partly add that functionality: https://github.com/meteor/meteor/pull/1332
The issue with that pull request seems to be that it only fixes the client side of thinges (ie. it only shows accounts from the selected domain when the user logs in).
But it does not add any server side checks.
Im using the following workaround:
In a .js file in the sever folder I have the following code:
Accounts.validateNewUser(function (user) {
if(user.services.google.email.match(/example\.org$/)) {
return true;
}
throw new Meteor.Error(403, "You must sign in using a example.org account");
});
This prevents accounts from being made for domains different from example.org.
If you want to only allow certain users from your domain, you could also add a whitelist collection that defines user ids from your Google Apps account. This way you can restrict access to only certain users, get single sign-on functionality, and can pre-set user roles and properties for your app before users even create their accounts.
Use the Accounts.onCreateUser(function(options, user){}) callback for that since it allows you to define additional user properties.
I'm working on a Drupal 6 module to provide OAuth-based user authentication and registration. I'm already using the OAuth module to authenticate as described on http://oauth.net/core/1.0a/#anchor9. The next step is to create the user account using information provided after authentication using an custom API of the Service Provider.
According to http://drupal.org/node/497612#comment-3047302, I should not use user_external_login_register() but see the OpenID module for how to properly login an external user.
After studying the OpenID module, here is what I plan to do:
Try to load an existing user for a authname build from the custom API result using user_external_load().
If a user exists, use user_external_login() to log the user in.
If not, pretend the registration form has been submitted (like openid_authentication() does) to create a new user account. And redirect to a pre-filled form if any additional information is needed in order for the user to register.
Is this the right way to do it ? Is there another module worth looking at for how to this properly in addition to OpenID ?
You could have a look at the former Drupal module. That module did two entirely different things (hooray for the architecture :)).
* It puplished information to a central "who runs Drupal" directory. (and offered a page to show such a directory yourself!)
* It allowed login with credentials from other Drupal-sites.
The latter is what you are looking for. Note that the module was discontinued, not because the method for logging in was done wrong, but because the DrupalID mechanism itself is flawed. It has been replaced with openID and oauth.
http://drupalcode.org/viewvc/drupal/drupal/modules/drupal/drupal.module?hideattic=0&view=markup
The hooks and methods you would be looking for (in that order) are:
drupal_form_alter -- Adds validate-callback to the login forms.
drupal_form_user_login_alter -- Adds information about alternative login on login form.
drupal_distributed_validate -- Validation callback: calls drupal_auth to see if the user is valid. If so, calls user_external_login_register
drupal_auth -- Helper for validation callback: determines if the credentials are valid.
All other functions are either helper functions for these, or provide that directory-feature, or allow remote sites to authenticate against our database. Neither of which you will be using.