Link to home
Start Free TrialLog in
Avatar of kkiddie
kkiddie

asked on

Multiple authentication prompts over web

Hi Experts:

Can you shed some light on this for me? I have a small web application (basically just a form) that users can access through the browser, fill in information and save again (nothing fancy, I know).

For security:

- I have created a role called [NonAnon] and added a readers and authors field to the form, each containing that role.

- Because this is a public app, I am using what we call a lightweight account in the address book (a person document, but no certificate -- authentication only on a password string).

- I've listed this account in the ACL and assigned it the [NonAnon] role, with Editor access.

- The form itself allows authors and above to create and read documents.

- Anonymous access in the ACL is set to None.

It all works fine (i.e. prompts to authenticate on accessing the document through the web). And the document goes into edit mode fine when the edit button is clicked. But when the save button is clicked, the document prompts to authenticate again, and then saves. Subsequent changes to the document do not require any reauthentication.

So basically each session requires two bouts of authentication -- one when first accessing the document, and one when first saving.

I would like only one authentication prompt when the user first accesses, though, with all saves not requiring reauthentication.

Any thoughts?

-Ke
Avatar of Sjef Bosman
Sjef Bosman
Flag of France image

Do you have logging enabled, e.g. domlog.nsf? Check whether in both cases the same URL was used, e.g. using
    http: //www.domain.com/filename.nsf/view/doc?OpenDocument
and
    http: //11.22.33.44/filename.nsf/view/doc?OpenDocument
might refer to the save server, but AFAIK the server considers it to come from a new user and will therefore require a new login.
   
Avatar of kkiddie
kkiddie

ASKER

They are logging with domlog.nsf, but for some reason today's traffic doesn't seem to be posted yet... I'll keep checking.

It's an good idea, but I don't think the URL is at issue.

I can tell you that the URL when accessing, (e.g. http: //www.domain.com/filename.nsf/view/doc?OpenDocument) is the same domain when the document goes into edit mode (e.g. http: //www.domain.com/filename.nsf/view/doc?EditDocument), and that the form method POST URL generated by Notes is a relative path and so should just be grabbing the domain from the address bar...
Ah, no, not always true. There are some Domino-generated URLs that are just plain wrong, despite the good intentions, although things have improved enormously since 4.6. If you use URLs yourself, they'll be correct, no doubt. Some URLs though, generated by agents and $$Return things could go terribly wrong. I hope that's corrected by now, but I can't tell because we used to generate ALL those URL's using one function, just to avoid URL changes.

Today's traffic? Try a view refresh with F9. Traffic should be in that database immediately. What Notes/Domino releases are you on?
ASKER CERTIFIED SOLUTION
Avatar of Sjef Bosman
Sjef Bosman
Flag of France image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
That's cheating!! ;-)
Sorry, what? I do not get you? Or do you mean Zvonko reads what zvonko has written? There can be only One! :)
No, I meant putting the document in Edit mode is cheating. It doesn't solve the problem, it's just a bypass.