I would like to make it so after the user clicks their email verification link they are automatically logged in.
How can I go about this?
Edit: It was as simple as
req.session.passport.user = newUser._id
Apparently all passport does is assign the user ID to a user session, so doing it manually did the trick. Then just redirect the user accordingly.
Look into deep-linking.
You need to redirect the user when they click activate (uri to app or url to a website). This can be done with Express's redirect function.
For apps, there is a scheme tied to the app (ex. myapp://) which opens the app if you have it installed. In that case, whatever payload you sent (authentication information) can be listened for and handled to log the user in automatically.
For websites, you need to redirect them to a url along with their authentication information. You'll be listening for that as well, and log the user in automatically on your website.
Related
I've created a React App which has the flow as following:
User Logs In Dashboard is opened
A list of books appear (written by the user)
User clicks on manage books
A new window opens which has information of that book. (Private Route)
Now the question is, the Private Route is only accessible if the user is logged in, and this works fine.
But when I try to copy the URL of the Private Route and open it in a new window, by logging in with a second account, the user sees the content of first user.
So my question is, how to restrict access of content to the specific user only?
Please help! A simple logic will help me.
I don't know for sure your app structure and I will assume that :
user2 tries to reach url /bookstore/bookOfUser1
user2 is not logged in, so he is then redirected to url /login with a mechanism storing the url that the user wants to access
user2 logs in, is redirecte to /bookstore/bookOfUser1 and an api call is made to get the book details with a book id (bookOfUser1)
During the step 3, when fetching the data, your backend should check if the user2 has the access rights to read the book details bookOfUser1. If so, your backend should send the details, if not, it should send an error handled by your frontend. Your frontend would then redirect to a fallback url.
I have a problem with vue 3 backend and nodejs mongodb. For example i have a user and admin role, admin role can access all menu in dashboard, but user only can edit their profile.
When i login as user and access edit profile menu, for example the url is localhost/profile/121 (121 is my user id), i will get my user data by id. But, user can edit the url id with another id, for example localhost/profile/122, and its not good.
How to prevent that user can only view or update their profile only? When at login page, i store the accesstoken, refreshtoken, id, and role in localStorage. And i see that localStorage can edited.
What is the best way for login in vue 3, nodejs with role model? And is that any way for prevent that user can only edit their data?
Thanks before.
Make sure that you have the id in the access token or the session.
Now every time a url is entered, see if the id is the same of the user, if yes, proceed. But, in case, it does not belong to the user, you can either redirect the user to the valid page or show unauthorized message.
My company has just obtained Kentico for some new applications. These applications will be going into production in about 2 weeks, so we are still fairly new with this. What we have are three ASP.NET MVC applications/sites that format and present content that is stored in Kentico. Additionally, we have specific users who will log into the Kentico9/Admin site to manage the content displayed by the MVC apps.
From a corporate standpoint, we also have Siteminder SSO enabled. When a user navigates to our Kentico9/Admin site, they are first authenticated by our corporate Siteminder SSO form using their corporate user id. When they are successfully authenticated, Siteminder redirects the user to the Kentico9/Admin site they originally requested and the user is presented with the standard Kentico login form. If the user has already logged in through Siteminder during another session, they only get presented with the Kentico login form. Otherwise, if this is their first time logging in, the user is required to login twice (once through Siteminder and again through Kentico).
What I want to do is bypass the standard Kentico login form and use the Siteminder information to Authorize the user to log them into the Kentico admin site. Siteminder adds the username and some other information to the HTTP request headers. Using C#, I can retrieve their corporate user id using the following: System.Web.HttpContext.Current.Request.Headers.Get("SM_USERID").
So, in a nutshell, I want to override Kentico's standard login form and write some code that will get the user id from the HTTP request header and authorize the user by looking up their userid in Kentico. If the user id is not found or is not active, present the user with the standard Kentico login form. Otherwise, if the user is a valid and active user, pull their user record and allow them to access Kentico.
I have found some tidbits of information and given enough time, I may be able to figure something out, but I am hoping someone has done something similar and can speed up my process. Any ideas on what I can do? I will also entertain anything that might have tighter integration with Siteminder, although it doesn't seem Kentico can handle Siteminder out of the box, but I am not sure about that.
Sounds like you might be able to create a custom webpart which you will place on a page and simply have Siteminder redirect the user to the page with that webpart on it and look for those header values on page load. If it finds them, perform your actions within Kentico to look that user up and authenticate them in Kentico as needed. If there are no header values or it can't find the Kentico info, simply send them to the regular login page.
You could also create a global event handler but that would require someone to click a button or such on your site after they have entered credentials.
I am using oidc-token-manager with OAuth and identity server to setup authorization/authentication on my site. All the functionality is working fine . I am just wondering what the id parameter is that is being sent to identity server
https://foobar.net/identity/ui/login?id=216257a45dbd3041eee88fa8aa5d3b0cidc
and more specifically can i use that, in some form, to add a button on identity server to send the user back to the page that they came from. To be clear the post login redirect is working fine . once the user logs in with his/her credentials it automatically sends them back to the website. However there are 2 senarios that i want to take into account to extend the redirection.
case 1 : If the user clicks login from the website and then is like "nah dont really want to log in anymore have to afk and deal with some stuff just get me out of here will come back to it later"
case 2 : The user is not registered yet and clicks the login button from the website instead of the register button . On the login in page there is a "dont have an account? create one now" button. But in its current form it redirects to the registration with no way to set the same flow as the login where there is an automatic redirect back to the website, which will actually be a specific page that tells the user that he has registered and has a time period to check his email to authenticate himself to the site.
This is using an angular app with the set configuration for the OidcTokenManager as
var config ={
authorization_url:'https://foobar.net/identity/connect/authorize',
client_id:'foobar_id',
redirect_uri:'http://localhost:5060/callback.html', // for testing
response_type:'token token_id',
scope:'fooscopes',
authority:'https://foobar.net/identity',
popup_redirect_uri:'http://localhost:5060/login-dialog.html',
silent_renew: true
};
Any help would be awesome . thanks
The id parameter that is passed to the login page is part of how IdentityServer manages the state for pending authorization requests. It's the id of the cookie that holds the SignInMessage that IdentityServer uses internally.
For case 2 if you click one of the additional links the id is passed along. It is then the responsibility of the custom page to get the user back to the login page with that id. I believe we have samples showing this.
I have written an agent which takes the username and authenticate user, if authentication is successful then it redirects to the actual URL of the database.
For taking name of the user, I am using #Formulas. Hence, I can use my method of authentication in any link or hotspot or button in Notes Client. But, I face problem to send this method through reminder email links.
When I create a URL through backend agent, this URL/hotspot should have my code with #formula. In simple words, I want to pass #Dblookup inside URL/hotspot through my email link. How to accomplish this task ?
Or is there any alternative to get user name if any person clicks a link in his email ?
Only Notes client has to be used.
Edit#1: Adding scenario for better explanation:
Our users are not happy to re-authenticate themselves for web applications. So, we have been trying something like if they want to open a webdoclink, which they got through their email in notes client, so they shouldn't be asked to authenticate again (since they have already logged into notes client).
We could achieve this for static application links, where application name is not changed. Now, the challenge we are facing is how to do it for reminder emails, which have links to particular web document (links here are not static. They are differed by unique document ids).
For this to work, we need shortname of person who clicked that link from his email.
You probably need to be sending an Action hotspot instead of a URL hotspot; but it is very difficult to guess without seeing what your code is really doing. Also, I believe that creating an Action hotspot probably will require copying it from a previously saved rich text field, perhaps in a profile document and appending it to the rich text body field of the message you are sending. (That's a technique I've used in the past to create action hotspots, anyhow. I'm not sure if there are better alternatives.)
And since this is for Notes client recipients, the other technique that I would probably explore is the use of a store-form-in-document message instead of an ordinary email message. That way you just need to have a button containing the #DbLookup on the form that you send in the message.
I agree with leyer. The ACL (Access Control List) is the main tool to use to decide functionality. For instance a user can have access to the db. Then you can define who can create databases, create emails. It is best to use the ACL so you can also use Roles and other tools. Basic LotusScript can access the ACL on open events or do a test in buttons.
Regarding the scenario you are describing, if the issue is that users have to re-authenticate for every web application on the server, you would be better of implementing SSO/Session based authentication on the server then coding this workaround. With Session based authentication, users only have to authenticate once.
From the admin help:
Session-based name-and-password authentication sends the client's name and unencrypted password, and is sent with each request to the server. Session-based authentication differs in that the user's name and password information is sent over the network only the first time the user logs in to a server, not each time a request is posted. After login, the user's name and logon information is stored in a cookie in the user's browswer, and the browser sends the cookie to the server with each request. Before honoring a request, the server verifies the information in the cookie and uses the cookie contents to identify the logged-in user. The session is only valid within the browser in which the login was performed. If the user shuts down the browser in which the session login took place, the user's session will be ended and the cookie will be destroyed.
Using session-based name-and-password authentication provides greater control over user interaction than basic name-and-password authentication. For example, you can customize the form in which users enter their name and password information. It also allows users to log out of the session without closing the browser.
If you are using windows based servers, you could even implement SPNEGO, automatically signing the users in using der Windows account, therefore eliminating login prompts completely.
With Domino 9, you also have the option of using Security Assertion Markup Language (SAML) to configure federated-identity authentication.
In your case, I would start with Session-based name-and-password authentication to solve the multiple-login issue.