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.
Related
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've implemented my own user login and logout system by just setting a session variable and checking it in my main template so I will display a login screen if not logged in and display the app if I am logged in (this is typically how I did things with PHP).
I did this instead of using any of the built in user account systems because I needed to implement my own login password check to a legacy web service.
Because of this, it seems I'm running into trouble now because things like allow/deny rules for my file uploads don't seem to have the userId:
download: function (userId, doc) {
console.log("userId ", userId);
return true;
}
This prints : userId null
So, I'm unable to implement any logic here based upon whether the user is logged in or not.
So, is there a way for me to tell the meteor accounts system what my userId is when I perform my custom login? --- which I presume would then make it available here in the download allow/deny rule?
EDIT: I've had to implement a custom login handler with Accounts.registerLoginHandler. Doing this caused the meteor system to set the userId in the built in accounts system, which allowed it to be passed into the allow/deny functions... but my question still stands. I would like to know if there is a way to alternately provide some information (say, the values of a session variable) to these allow/deny rules instead of being limited to using the built in accounts system.
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>');
}
I'm a new to Drupal but I just want to hack/customize the login function of Drupal 7, like hardcoding. As i have discovered that Drupal 7 login process is handling by user.module and its associated files.
I just wanna know which kinds of values or properties are returning or providing when a user logging/authentication process is done by providing just Username/Password.
The final properties it returns, to provide back to Drupal (along the whole authentication process) that I just noticed so far are:
{uid} of the attempted user
{rid} role id of the user
user email
user is blocked or not
then .. ?
The point is .. what other else?
Can i replace/modify the whole existing authentication process? (as i need)
For example, one of the default auth functions in user.module:
function user_authenticate($name, $password) {
..
return $uid;
}
For example, if i modify (hardcode) that function to connect to my other external database(s) and return {user id}, the Drupal will get one auth requirement {uid}. Then what other else to provide? User Role and .. etc etc ?
Like that .. what other functions and properties else should i touch and provide back to Drupal along the authentication process?
This is not an actual answer but I cannot post this as a comment.
Basically we do not hack core. So looking at the user.module's code will not help you very much than learning the hooks. For an example, It's difficult to get an idea about how to add some magic when a node is created by looking at the code of hook_nodeapi(). But if you check the docs and the return/input arguments, it's much easier to do the job.
I'd start by adding an extra submit handler to login form using hook_form_alter(). I have seen some other threads from you about your use case but unfortunately it's difficult to provide a sample code for you.. You can see how other modules implement extra authentication (e.g: http://bit.ly/LdRcm6). (See how Remember Me module adds a checkbox to login form and twitter module that allows twitter login).
Then, you can have Drupal to authenticate the user as normal, and your new custom functionality in addition the Drupal's authentication.
Drupal can even connect to external databases no matter if it's Drupal or not.
As you can see in many functions, they returns a Boolean value or sometimes, the user ID. user_load() is the function that loads a basic user object.
Remember it's modular. Some modules can include/remove/alter these values using hook_user_load(). user terms module and profile module is a perfect example here. It includes profile field information when other modules require user information.
A single user is not just a set of information. It can be modified during any part of the process. So do that. Use your module to provide information that your external site has.
{uid} of the attempted user
{rid} role id of the user
user email
user is blocked or not
user last login time.
user register date.
...
To see the entire object for your site, enter the following.
<pre>
<?php
$user_account = user_load (1);
print_r($user_account);
?>
</pre>
You can enter this code in a node create page where you have php filter used.
Without hardcoding, you can allow other modules to make use of these values. Even if your source database has no role ID, you can ive them a role ID, a user ID, and such.
Good luck!
Drupal is an extensible system. There is no need to do "hardcoding" in core modules like the "user" module. You should rather explore the hook system that allows extending the core (and also contributed) modules.
And in case you want to fetch user id's from a different database (I am not clear about this usecase), you can still use the roles, and other user data, from Drupal's database.
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.