Auto authentication through email link

0
votes

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.

3
lotus-noteslotuslotusscriptlotus-formula
Are these emails going to Notes client users? – Richard Schwartz
@RichardSchwartz: Yes. For web, we don't have problem. But this problem is with handling Notes Client emails only. – Ravi Gupta
I do not understand. Authentication is usually done by the server automatically. You do usually not have to write code for that. Could you expand on that a bit, so wie understand the problem better? – leyrer
@leyrer: I have updated my scenario – Ravi Gupta
Why not just send notes:// links instead of http:// links to your Notes users? Then they wouldn't even have to launch a browser and there would be no need to authenticate since they are already logged into the Notes client? – Richard Schwartz

3 Answers

0
votes

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.

0
votes

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.

0
votes

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.