Usually when you create an account to some webpage they send you an email with a link in order for you to validate your account.
If you click that link then you account is validated and thats the end of it.
How does this work?
Is that url unique for every new user so they know who visited what?
This is not a web service related question, however I can conceptually guide your through what you need to do.
When a user registers their information will probably be captured into some user table in a database somewhere. This user is marked as pending. The system can then generate a unique id i.e. a GUID which is stored next to the user entry in the database. This GUID if properly constructed will be impossible to guess. This GUID is then added as a GET parameter to the URL that you in an email to the user.
For example you might have the URL:
http://example.com/activateuser?confirmuid=5e706449-2cbf-4938-8109-fb564c196d8f
Thus every user will use the same URL with different confirmuid parameter. This URL will then post the confirmuid to the page where you can then use this value to look up the user in the database and then active the user or move it from a pending state to an active state.
Simple right.
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.
A strange situation that I am unable to find other people having to deal with. We are using Microsoft AspNetCore.Identity to handle our authentication. Everything is working fine.
The problem is that for a user to perform certain actions, they MUST get another user to 'sign' that action. This act of signing of course requires that other user to use their user name and password to sign the action.
The issue with this is that the other user's details are readily visible in the request payload. So if I am sneaky, I can open the developer tools in my browser (and hide it), then ask my admin to come and sign my action, and when they have gone i can go to the network tab and see their username and login in plain text!
Of course this is all over https but still, we can't allow one user to see another's sensitive information.
How are we to manage to allow a second userB to 'sign' an action for userA while in user A's active session, while removing the capacity for userA to steal userB's credentials??? Any ideas? (Front end is angular.js)
I imagine it's a big rework, but instead of having the "admin" sign the request on the user's machine, the admin could receive a "user A requires this action to be signed, proceed? [ok] [cancel]" on their account, the action would be stored in the database (perhaps temporarily?) & then all of the sensitive information is kept within each user's session with no cross over.
Then the authentication of who is permitted to approve actions can be handled in the backend via standard identity methods.
The user's "Please wait while an admin signs this action" modal (assumption) could then poll an API to determine the status of the action and then proceed once accepted.
I second #justcompile's answer if you need an authorised and authenticated user to sign/confirm the action, more work but the only secure way.
If you just need a second pair of eyes to confirm you could message a private group or slack channel that only "authorised" people have access to with a one-time URL containing a token (that maybe expires after a period of time too).
Assuming admins only access that channel they can follow the link, the app can validate the token and confirm the action.
Saves a second (admin) user logging in on their own machine and the need to build a workflow and UI etc, but again exposes you to risk if nefarious types get access to the channel or the links sent to it.
Depends on your appetite for risk I guess.
another user performs signing action on your local system? and you are sly?
there is no way to protect their password.
use two factor authentication.
The way this would normally be handled is for the user to request an action. This (unsigned) action-request is recorded in the database. The admin user is able to see this unsigned request in their account, and make an (authenticated) request to sign it. The user would be able to see the status of their request, and whether it has been signed yet.
Im running a Azure Webapp with application insight.
I know Microsoft cant show the real IP (Client_IP) so I add the real IP address to all requests (Ip).
I have a visitor client_id="h9zbt" that in the last 24h is using 48 different client_IP adresses.
The same user also has several real IPv6 adresses.
I like to block this IP from my website, but I think this looks so strange.
Is it really the same user?
How is Application insight tracking the User_Id?
Image link
Usually application insights is automatically opening a session automatically for each user (look for the ai_session key). Therefore the default user scope would be a session scope.
You can override this behaviour by sending a user context if you have some kind of sign-in. (https://learn.microsoft.com/en-us/azure/application-insights/app-insights-usage-send-user-context)
I find it likely that it's the same user on the same device, just using several IP-addresses, maybe as an unsuccessful attempt to stay anonymous.
User IDs should persist across user sessions to track how users behave
over time. There are various approaches for persisting the ID.
A definition of a user that you already have in your service.
If the service has access to a browser, it can pass the browser a cookie with an ID in it. The ID will persist for as long as the cookie
remains in the user's browser.
If necessary, you can use a new ID each session, but the results about users will be limited. For example, you won't be able to see how
a user's behavior changes over time.
The ID should be a Guid or another string complex enough to identify
each user uniquely. For example, it could be a long random number.
If the ID contains personally identifying information about the user,
it is not an appropriate value to send to Application Insights as a
user ID. You can send such an ID as an authenticated user ID, but it
does not fulfill the user ID requirement for usage scenarios.
mentioned in Azure doc.
https://learn.microsoft.com/en-us/azure/application-insights/app-insights-usage-send-user-context
Our web app. sends reports out to users which contain links that point to various items within our web app. (specific records). Users ordinarily have to login to our system to access it, so I am wondering what the best methods are of allowing one of these links to direct the user to the area of the system, without them having to repeatedly login.
When you create a link, you can note which user this link is for. When user clicks on the link, fetch information for the user. Guid in your url would guarantee that no other person can guess path for that users data. This will not technically authenticate a user. But will allow them to see data you need.
First of all it's bad idea to distribute user credentials even to a known email address.
You can generate a unique key for each customer and insert it in query string of included URL in the email. once user clicks on the sent URL, system discovers which user is dealing with and authenticates user. After successful authentication process it really makes sense if you disable the sent unique key.
On my site, a user enters his email when creating an account. After submitting the form, a new user row is created in db with the respective email. This row has inactive flag set to True. Next, an activation email is sent to the entered email address so that the user can activate his account and login afterwards using the email and password. There is unique constraint on email in db for login to work correctly.
The problem is that someone can use an email of another person, blocking that other person from ever registering on my site. There already is an (inactive) account with the email that the legit user tries to enter so new user row can't be created. I am not sure how to tackle this problem exactly. It probably has a good solution because the registration scheme I use is pretty standard.
From my view point, I have a solution like that:
When user register with the email. I will generate an unique key (may be user-id) that will attach into the link activate in the email content. When user click to activate account we will get that unique key to update to confirm from user. That solution will help you disable an user following user id instead of disable following the email which can be duplicate.
Hope this help.
U cannot find the person's mail id who misused other's mail id so its not possible to an extent.
You could delete the database entry with the email after some time, if the activation link has not been clicked. Depending on your operating system, you could use cron or systemd timers (Linux) or scheduled tasks (Windows) for that.
For example to execute a MySQL query from cron this question might be helpful.