I have my _users database secured, so a user can only access their own information. However, I'd like other users to be able to retrieve certain public information such as email addresses, real names, and phone numbers. What's the best way I can go about accomplishing this?
You can store the info in the _local database, e.g. _local/userinfo.json. Of course you need to know the url of the other users.
Related
This is the my web-app "User Settings" page.
I have simplified it to a minimum to better highlight the problem.
To authenticate users I use Auth0, I wanted to use the sub claim user_id to identify the users inside my MySQL database for update and retrieve user's info. Unfortunately the user_id is different for each provider, for example, if the same user with the same e-mail logs-in via Auth0 he gets a user_id if he does it via google he gets another one.
I thought about using email to link logged user to his info.
The problem is in my API. Before the change it was "localhost: 8080 / api / users /: id"
each time it created a new id and in any case it was impossible to recover the data of the single user. Now that I have replaced "id" with "email" my API has also changed in "localhost: 8080 / api / users /: johnsmith#xxx.com".
Before:
After:
In a few words, the request url on the client side has also changed.
I would like to make sure that the GET and PUT requests are made based on the e-mail of the logged user without going to modify the whole back-end.
Sounds like something is wrong with how you authenticate users. If you have multiple ways to authenticate a user, those methods need to be in a one to many relation with the user. For example each user has a list of auth-methods, and whenever an authentication is made you check your table of authentication methods and find the one user it maps to.
Im not sure if you are doing this yourself or if the framework you are using is handling that, but it sounds like you need to change the model to allow many Auth methods for a single account.
Also you could use email, but that is also an "old" way of uniquely identifying users almost every single person has multiple active email accounts nowadays, so you should also have a one-to-many relation for users to emails. What if the user has different email accounts for their Facebook and Google accounts?
See account linking here: https://auth0.com/docs/users/user-account-linking
It is dangerous to trust that the external providers are truthful about what email belongs to who. What if I open a new account using someone else's email on one of the providers? Then I can log into that users account in your application, which is a pretty big security risk.
If a company makes available its user ids in an external database, but not the passwords, and if this database gets hacked, how easier it becomes for the hackers to then brute force access to the internal network?
You shouldn't share your user ids with external application without masking. For example;
http://www.example.com/user/1/edit
http://www.example.com/user/2/edit
From external application user will see above urls. That means anyone from outside of the organization will be able to enumerate whole database like number of users, user ids and username match-up etc.
You can use http://hashids.org . It's generating short unique string from integers. With that way, external application will only see masked values rather than actual ids.
http://www.example.com/user/a8sf71/edit
http://www.example.com/user/d0nd1d/edit
Does anyone know if it is possible to create a login in XPages / Domino, where one can create their own users who are not on the Domino server.
I need to create a database that has users connected to a customer.
Customer further orders that they want to see. There can be several hundred customers eventually.
The reason I want to create a separate database for users is that users will have different rights and fields than those found in Lotus names.nsf
You could use a separate NAB and add it via Domino's Directory Assistance to the server.
This allows you to create the external users from the other company in this NAB only and won't affect your companies names.nsf.
The external users would have their own company hierarchy, something like
*/Acme/US
f.e.
Mary Jane/Acme/US
The can login with the default Domino mechanism (including the password change mechanism etc). And you can use the other features of Domino like Groups, ACLs etc.
The users would log on to your site with their email adress, that's why there is no be problems with "doubled users" (Hans Mueller/Acme/US and Hans Mueller/YourCompany/US).
The DA must only run on the Webserver that the external users should access. You don't have to replicate it all around in your infrastructure.
EDIT:
You can create user documents in this external NAB without any problems. I prefer a self-registration with a email validation mechanism (to prevent the use of an internal email adress, f.e. of Hans.Mueller#YourCompany.com).
The users can choose their own password. All you have to do is to create a new Person document in the NAB and do a Compute with Form (this sets the HTTP password).
If a user wants to change the password, you can use the ?ChangePassword functionality. And if a user forgets his password, an agent creates a new one in the person document and sends it via mail to the user email address.
I want to create a dating app where the app user would search for matches based on gender, age, and current city, even if those matches are not friends. I'm assuming that there's no way to search all the app users without providing a UID;is there?
Would I need to store those variables in my DB, and then use each UID to get its respective profile info?
Yes, you can only get the app users from the authorized user, but not just all of them. And for a dating app profile, all users might want to have their own profile stored in the database, with additional info (not available in Facebook). But be careful with privacy, whenever you store any personal data, let the user review and edit it first.
I would like to collect analytics on multiple visits from a logged in user, if they opt in.
But I would really like to do it in a way that only the user can link their user account to the anonymised analytics entry. This means, when the user is logged in, they can manage the analytics information stored from their visits, but site administrators won't be able to link the analytics entries to that account (the analytics data and user data is of course stored separately)
Ignoring implicit links in the analytics data (such as user identifying URLs etc), what would be the best way to implement this? Is it too dangerous to use a secure hash of the user's password and account ID to identify the analytics information? (the site administrators won't have the user's password, so won't be able to link the records).
You've dressed this up so that linking a user account to data is not predicatable - but that doesn't mean it that the information is therefore hidden. Regardless users will be making a requset based on a key, which is exclusively derived from their account - so really its just security by obscurity. Since it must be possible for the system to reconcile the users identity with the key against which the data is stored it is therefore possible for someone with backend access to derive the association - even if only at the time of access.
The only way to prevent this is to store the data on a machine where these admins don't have access.