There is a way to allow duplicates usernames (between different users) at sign Up using accounts-ui? I'm using in configuration:
Accounts.ui.config({passwordSignupFields: ' USERNAME_AND_EMAIL' });
Usernames are allowed to be duplicates in my app (as facebook allow create different users with the same name) but only the email should be the unique between users for sign In later with email/password.
Any advice?
You're going to have to roll your own authentication. Meteor Chef is a great place to start with this.
You won't be able to use accounts-ui to do this without hacking/changing it to suit your specific needs.
Best of luck to you buddy!
Have you tried this?
Accounts.ui.config({passwordSignupFields: ' EMAIL_ONLY' });
Source : http://docs.meteor.com/api/accounts.html#Accounts-ui-config
Also you could just save the username in users profile
Related
I have a Flutter app where most of the users should never log in. I also use this same app for a small selection of users that I personally manage and would like to allow them to create a Firebase account, preferably just with by giving them a password to access the account creation page. Ideally I don't want just anyone to be able to create an account, only those who I have personally given access to. Is there a way I could password protect the account creation page so that only those with access to the password could create an account? Perhaps there is another way to do this? Ideally, I'm not looking to get into a situation where anyone can create an account and then downstream I have to authorize that account so that it has the correct access. I really just want only those with the access upstream to be able to create the account. Perhaps this is not logical but this seems to make more sense than letting accounts be created by anyone and then approved by me after the fact. So my question really is, how do I password protect a page in flutter? Or is this just a bad idea and should I work to manage things downstream? Or is there another solution I have yet to consider?
Have you considered using something like a dynamic link that navigates to the specified page in the app when clicked. firebase_dynamic_links might be of help. Only those who have the link will be able to access it and I presume that you could manage the link actions from the Firebase console.
You could also opt for simplicity and create a password field that pops up before your account creation page
I'm trying to come up with a way to secure a set of Admin CRM pages that control a Meteor application I'm working on. There's just one codebase, with the server, customer facing website and admin facing website in one project.
I need a login page which can verify one username and password pair, and a simple way to check the status of the user on both the client and server side. I also need a way of the admin's authorization timing out if it hasn't been used for x minutes.
I've looked at the meteor accounts package and it's just way too much fluff for what I need. This website will only ever have one admin user, so there will only be one set of admin username and password to store. I don't want it stored in the database, rather loaded with a settings file on the server on application start. It doesn't need roles, emails, password reset functionality.
Any recommendations for a package or approach I could use to implement this?
I know you said that the accounts:password package seemed a little "overkill", but in reality it really isn't. What you are gaining there is pluggable UI (via accounts-ui and other packages that build off it). The approach I have taken is this (which happens to work well even for apps that do support multiple users, since ultimately you still need to bootstrap your start users).
First, I use a combination of accounts:password and alanning:roles. If you absolutely don't need the roles portion, you could probably get away without it, but in all my personal cases I have found it useful to have multiple levels of ACLs for the various users. We could get into a whole philosophical discussion on using roles/groups to lock down individual features, but that's sort of off topic for this discussion.
Next you need to boot-strap the user(s). Somewhere in your /server folder you will do something like:
if (Meteor.users.find({}).count() == 0) {
// No users created...create default users
Accounts.createUser({
username: 'myuser',
email: 'myuser#mydomain.com',
password: 'myp4ssw0rd!',
profile: { profileProp: 'propVal` }
});
// Add new user to whatever roles needed
}
There are some more things I usually do here, like checking to see if my roles exist, and if not, create them before I try to handle the users, but the key here is to do that when the server starts up.
Once you have your user(s) and role(s) created, it's a matter of checking/verifying the user/roles in your app. For menu items you can show/hide stuff based on whether the user is logged in and/or has a certain role, and you should also verify in your application routes that require ACLs, like your admin route. In addition, use the user id in all your publications as well to limit the data your users can see. Don't rely solely on hiding a menu option...security through obscurity just doesn't work.
Why do I suggest doing it this way? First off, it's really not THAT much code. You could literally do this in probably 20 lines, max, and have a full authentication setup. And the benefit of those lines of code greatly outweigh the 30min tops it would take you, as you will now have "real" user authentication in your app and have the ability to do things like OAuth if you ever decide to in the future. Most importantly, you unlock pre-build UI plugins that you don't have to code, built-in and add-on methods to help check ACLs, the ability to lock down data by user, and you don't have to try to implement your own solution.
I would like to make some modifications to the meteor accounts system (remove email address, put phone no. in its place). My question would be how to do that (i thought of modifying accounts-password), and how to do that (e.g. creating a new package, or simply rewrite the git cloned accounts base)?
Thanks a lot!
The meteor accounts package does not require an email, users need either an email or a username. So you could use their phone number as a username and stick with the default package.
See: http://docs.meteor.com/#accounts_createuser
On the client, you must pass password and at least one of username or
email — enough information for the user to be able to log in again
later. On the server, you do not need to specify password, but the
user will not be able to log in until it has a password (eg, set with
Accounts.setPassword).
I have an active field on the users collection and I want to prevent the users with that field set to false to login on the application. I could allow them to login in the future, so I can't delete their account or change their password. How can I disallow them to login in meteor?
While this does not stop them from logging in directly it will logout them out as soon as they login which depending on the your use may work as a hack around:
Meteor.autorun(function(){
if(typeof Meteor.user().blocked !== "undefined"){
Meteor.logout(function(){alert('Your account is blocked at the moment, please contact us for more information');});
}
});
Where blocked is the invalid account attribute you have set
Probably the safest thing to do is to move the user's data to another collection and delete the user's account. Of course that may not be desirable if existing data in the system is linked to that user's id.
I looked through the docs and couldn't find anything that sounded like you could set an account invalidation flag (this seems like it would be a really useful feature though).
Warning I am not a security expert. The following advice could be awful:
If you need to leave the user account in place, one thing you could try is moving or modifying the SRP data in the user's account. For example you could just append the string '--disabled--' to the 'services.password.srp.salt'. That will prevent the user from logging back in and clearly you can reverse the process just by removing the string.
My users access Drupal through SSO and everytime the server authorizes them, it returns a set of permissions (groups/roles), according to which I need to dynamically set the User's forum permissions.
So for example if a User logs in and the SSO says that he has enrolled in a course, I need to give him specific permissions for that course's forum.
Obviously I need a custom module for that, but it's a little hard to start.
I'm thinking of using the ACL module's API, but I can find any documentation or tutorial online. Is there any?
Is there a better way to get around this?
I'd appreciate any help :)
(note: I know there are modules with GUI that have similar functionality but I need to do it programmatically)
We just put something exactly like this into place - we used the Rules module (with the User logged in trigger), checking the LDAP groups that the user is enrolled in, and assigned the role accordingly.
Check out Forum Access. It can restrict users based on their roles.
You could have your roles be something like "CSC221 Student". If a user has this role, they will be able to access the CSC221 forum.
Create a hook_user function ( see http://api.drupal.org/api/function/hook_user ) in your module.
Then using http://drupal.org/project/permissions_api set the appropriate permissions on the user.