Hi Bob,

Firstly, I'm assuming all design elements in the application are signed with the same ID? It might be this one page has been modified recently, but not by an ID with signer rights possibly?

Secondly, are you certain the server is up as single server? This sounds similar to an issue I have had in the past where the server was configured for Multiple Servers (SSO)

Try using the fully qualified internet host name of the server in the URL. This should work if its set to multiple servers.......

I'm the developer and all the elements are signed by me.

We have two Internet Site documents

The Default Site Session Authentication is set to Single Server, but the LocalHost site is set to Disabled.  Would users onsite be using the LocalHost one?  Perhaps thats the issue.

I needed to stop people from opening the same application in a second instance of a browser window, but they can freely move between pages in the same browser instance. Could you not save the UNID of the document redirect to a page with the same UNID but a different "form" then return to the original. So long as one does not change the database it should not be an issue. In my case I have a number of different databases that contain the actual data, but all XPages design and code is contained in one master  database. So my URL always loads the design from the same database, the page determines where the data is stored and retrieved.

I think your issue is opening the document in a new browser window. Unless I'm missing something that should not really be necessary. Store enough info in sessionScope variables to ensure that you can navigate back to the original window.

The input xpage is               server/path/db.nsf/xpage.xsp?action=opendocument&documentid=docunid

and the printable page is   server/path/db.nsf/xpage_print.xsp?action=opendocument&documentid=docunid

Everything is the same except I display the document using a different xpage - formatted for printing.

Just to throw another wrinkle on the fire, when I asked the IT Manager to try it, he was able to open the printable window with no prompt to log in.  Maybe that's a clue...

between your access rights and his? Tracking down these sorts of differences can be a little tricky at times.

As a developer that  that supplies applications to companies I have very little control over security model and infrastructure so I do run into these sorts of issues from time to time.

However, if it works for someone but not for you the ACL would be the first place that I would look. 

I had to put a call in to IBM and it turns out that the one Group that we had the users assigned to was corrupt.  We added a couple users to the ACL explicitly and they were able to open the printable window just fine.   So, after adding them to a new Group document, we removed them as listed explicitly and now they can still get to the page without another signin prompt.

Never would have guessed that.

Thank you all for taking the time to chime in.