Web Authentication Problems

HCL Domino Domino Forum
1

I’m getting some problems with HTTP connections to our Domino Server. Here’s a brief description:

  1. User connects to database as Web client and authenticates OK. Granted access as “Editor”.

  2. User opens a document from a view, edits it and saves it. No problems found. Document has no readers or authors fields. No adverse messages in logs.

  3. Application sends user back to the same view as step 2. Subsequently, when user attempts to open any document, server requests re-authentication. User re-authenticates and continues OK. At every attempt to re-open any document from the view, re-authentication is requested by the server.

But - occasionally, re-authentication is not requested. There do not appear to be any relevant error messages in any logs.

Has anyone else encountered this peculiar behaviour? Does anyone have any suggestions as to possible causes?

2

Subject: Web Authentication Problems

Hello,

Check the Anonymous entry in the ACL . Hope u get a clue from there.

Tom

3

Subject: RE: Web Authentication Problems

Thanks Thomas. Anonymous is No Access. That’s deliberate as only authenticated users are allowed access as editors.

4

Subject: Web Authentication Problems

The cause of the problem cannot be resolved. The current state of play is that:

There are two databases, TS2.nsf and GeneralComms.nsf. GeneralComms contains a URL to TS2.nsf. All users are web users. Both are on 1 server, EASTINT. The normal procedure is that the user authenticates against GeneralComms.nsf and this authentication is used also within TS2.nsf. The first time the user The ACL levels of both databases have been checked. There appear to be no relevant entries in log.nsf or domlog.nsf.

We see the re-authentication problem if:

{A1} We access TS2.nsf through GeneralComms inside the store network.

{A2} We access TS2.nsf through a copy of GeneralComms (made by copying GeneralComms to another temporary database, then copying back to GeneralComms.nsf, overwriting the original)

We do not see the re-authentication problem if:

{B1} We access TS2.nsf directly inside the store comms network (i.e. without using the URL in GeneralComms.nsf).

{B2} We access TS2.nsf through GeneralComms.nsf or directly but outside the store comms network.

{B3} We copy GeneralComms.nsf to another database name in the same location (e.g. GeneralComms2.nsf) and access TS2.nsf through the normal URL link inside the store comms network.

If this was an ACL problem, then we should not observe the difference in behaviour in {A1} and {B2} - the databases remain the same and the server is the same.

If this was an application problem, then we should observe no difference between {A1} and {B3} - the applications remain the same.

If this was a network problem, then we would probably not see the difference between {A1} and {B3}

Curiouser and curiouser . . . if anyone can shed any light on this, I’d be grateful!

5

Subject: RE: Web Authentication Problems

Hi Simon,

try to use the full qualified hostname in the url (including the domain name) or check that you don’t mix it (with/without domain).

But if both of your databases lay on the same server it will not do matter…

6

Subject: Web Authentication Problems

Did you try the same with an another browser? Another proxy settings?

Did you use the full qualified domain name by http requests?

7

Subject: RE: Web Authentication Problems

Hi Vladimir - thanks for your reply.

Did you try the same with an another browser?

  • No; this is an intranet application and the only browser we can use is IE.

Another proxy settings?

  • No proxy used. However, there is a firewall.

Did you use the full qualified domain name by http requests?

  • No. I nearly always use relative URLs, e.g. /ts2.nsf/form?openform

I’ve posted a bit more information . . .

8

Subject: Web Authentication Problems

I did cure this problem, but still don’t know why it occurred. I made a copy of the database in question. When I used this, the problem disappeared.