I would like to store one user preference per iOS and android device in a database.
Ideally it would be per user but as I don't want to maintain a login system. I want to do it this way.
How can I do this?
Note first that you can use the anonymous user system to create users for you and you could look at using that. You could also create a real user with randomly generated (UUID) username and password which are then stored in the keychain.
Alternatively, use the installation which is created for each device.
Related
A toy example:
The application NFTApp created a new account throwaway.near for a new user and minted some NFTs into it. NFTApp has the only full access key to throwaway.near. The user doesn't even know what a seed phrase is.
At a later time, the user decides they want to take possession of this account and its contents but name it keeper.near. Maybe they have created keeper.near previously or maybe they create it fresh as part of this process. Either way, the user controls the only full access key to keeper.near.
NFTApp then deletes throwaway.near and recovers the storage tokens from it.
How can we effect this handoff without needing to manually send contents from throwaway.near to keeper.near?
I am working on a Laravel project. I need to be able to create a user, mark that user with a number for their 'plan_id', and then invite them to log in and change their password. Currently, I am creating a user, adding the 'plan_id', and setting the password to a generic term like 'password'. I don't have info like their SSN or DOB that I could set it to initially.
While this does work, I don't know that it follows best practices. The only other thing I can think of is setting up another table that matches up the user's email address to the 'plan_id'. I don't want to do this because it makes it possible that the user accidentally signs up with another email and can't figure out why their portal is not working.
It doesn't sound like a great idea to set all new passwords to "password". It looks like your application is creating users, then letting each user know they have an account, as opposed to the user initiating this process. This would mean that you can't have the user pick a password.
Consider not creating a password at all, but sending an email to each new user containing a link to your system with a unique key that you store in the database user record. The user could then access the system, and it would ask them to pick an email and password to be registered with. You could have the keys expire after a number of days.
The easiest way to do this would be to generate a completely random password for the user and then email them a password reset link. The potential pitfall of this is that password reset links expire, by default after 1 hour though you can change it in config/auth.php.
Is there any way to login other users account for admin user ?
Currently authentication based on Meteor Accounts
I saw this post but didn't working at all now.
The feature is important for us because when user have problem in system then admin need to see it this by simulating user account.
Thanks in advance.
It seems you want to impersonate a user. This means that you want to have Meteor.userId (or this.userId depending on context) reflect the _id of a specific user both on the client and the server.
afaict the only way to do this is to login as the user. Presumably you don't want to ask the user for their password so you have a couple of choices:
Save their existing password, replace it (temporarily) with a password of your choosing, then after you're done impersonating their account, restore their existing password.
You probably don't want to ask the user for their password and you don't need to. All you need to do is set aside Meteor.user.findOne(userId).services.password.bcrypt, then reset the password to your temporary value, then restore the original bcrypt value later.
The downside is that the original user would not be able to login while you are logged-in. Plus it's really hacky.
Extend Meteor's Accounts package to provide impersonation capability in a more elegant manner.
You might also look at validateLoginAttempt. The docs are unclear as to whether a failed login attempt could be overridden with a successful one but if it could then that would provide another pathway to solve your problem.
Instead of logging in as the users, which requires their password and which is a total no-no, you may use rather alanning:roles and allow the admin to assign the role of any user in order to draw views based the user's role.
This requires a well designed role system.
As a plus you could then at least load the documents associated with the user who you want to support.
This requires a well designed document and data model.
But generally spoken you should rather focus on writing good tests (test driven development) for components as unit tests, integration tests and UI tests.
This will reduce the need to manually view the app as an end user a lot.
The most common end user problems can be reduced by creating a good knowledge base like a wiki or video tutorials.
Even if then an error occurs in the end user side, I would rather try to implement a well designed error log that allows users automatically create tickets on error which also include the error stack.
All the above methods are to be favored before logging in AS THE USER.
As #Jankpunkt has already mentioned alanning-roles I can add something you can use without installing any external package.
Just keep a type key in the profile object of the users collection. Then define some types like 1 for super-admin, 2 for admin, 3 for general etc. Then check the authorisation of particular action by checking the value of user.profile.type key.
Caveats: Make sure you are checking the type in server side. By default profile field is writable from the client end, so if you are putting type field in the profile object make sure that you are not allowing users to modify users collection in the client end.
Here is how to restrict client end update in users collection:
Meteor.users.deny({
update() { return true; }
});
Read more on roles and permissions here:
https://guide.meteor.com/accounts.html#roles-and-permissions
I have an app that uses parse.com as backend.
If I want to store information about user's in-app purchases in table there, how can I be sure that some guy is not going to create a simple app where users of my app can log (like in my own) in and write in parse-tables whatever they want (for ex.: that they made in-apps when they really didn't). This info is used to give the user access to app's features so it's important that the user really paid for that.
Don't make the table name public knowledge, so don't ever access it directly from the app, always use cloud code. Pass the cloud code some salted hashed details to verify against, and do the verification on save of any new objects being added toot that table with a before save hook. Drop any new objects which don't pass the test.
I am writing an app and would like to do the following: When the app is first used it prompts the user for a username given at the time of purchase. When entered this is then stored and cannot be changed.
I am unsure whether this is possible or if it is what method I should use to store it. I am right in thinking this is one for KeyChain?
Any advice much appreciated.