This forum is closed to new posts and responses. New discussions are now taking place in the IBM Developer Answers forum.

May 13, 2016, 8:06 AM
94 Posts
topic has been resolvedResolved

Why would users have to log in a second time to the same application?

  • Category: XWork Server
  • Platform: Windows
  • Release: 9.0.1
  • Role: Developer
  • Tags:
  • Replies: 6

I'm developing a new web based xpage application for a customer.  They requested the ability to print one of their input forms, so I created a formatted 'printable' version.  I then added a link to open the printable version in a new, smaller, browser window so they could print it, close the window and return where they left off.  This approach works well at several of my other customers.

The problem we're seeing is that the users are prompted to log in again when the printable window comes up.  What's worse is that they cannot log in.  The log in page returns 'you are not authorized'.  These are Notes mail users, logging in with their Notes ids.

The website document on the server is setup with Session Authentication = Single Server, which I thought meant that once they logged in to the application, they wouldn't have to log in again.

So, two questions really - why do users get prompted to log in again to the same application (just a different xpage in a new window) and then, why can't they log in, getting 'you are not authorized'?

Here's a screenshot showing the error:


I prefer that they would not get prompted to log in a second time.


May 13, 2016, 10:37 AM
93 Posts

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.......

May 13, 2016, 10:55 AM
94 Posts
Yes, it's all signed by me...

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.

May 13, 2016, 11:53 AM
453 Posts
Are all the XPages design elements in the same database?

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.

May 13, 2016, 12:06 PM
94 Posts
Yes, I agree - it shouldn't be an issue, but...

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...

May 14, 2016, 11:41 AM
453 Posts
So what is the difference in the ACL

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. 

May 19, 2016, 4:57 PM
94 Posts

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.

This forum is closed to new posts and responses. New discussions are now taking place in the IBM Developer Answers forum.