Notes/Domino XPages Development Forum - Xpages URL Redirection 403 error

Jun 7, 2012, 5:29 PM

135 Posts

Re: Xpages URL Redirection 403 error

I just learned about reserved words in URL parameters (another very strange behavior in XPages!) a few days ago . I'm not sure if they are documented somewhere but when using reserved words you'll need to get the URL parameter the hard way, using:

facesContext.getExternalContext().getRequest().getQueryString();

and parse from there. Here is an article about this:

http://xpageswiki.com/web/youatnotes/wiki-xpages.nsf/page.xsp?documentId=E1D3910F957E1325C125770000274F3A&action=openDocument&SessionID=CWLCLVH8ZQ

It's interesting though that the problem occurred only with longer parameters.

Anyway it might be better to use scope variables, in this case requestScope or sessionScope.

HTTP 403 sounds like the user does not have access to the XPage or some resource the page is referring to.

- Panu

~Mario Kikiploplen

Jun 8, 2012, 7:45 AM

2 Posts

Re: Xpages URL Redirection 403 error

Thanks for your reply Panu,

It is strange that it is only for long string , but also in our development server, it is working fine with that Login . They have both version 8.5.3 , the only difference , is that one is accessible only in our domain , and the other from outside.

~Alexis Minlutex

Jun 8, 2012, 8:00 AM

135 Posts

Re: Xpages URL Redirection 403 error

Now that I thought about it I believe the reserved parameters should not really be used. For example Login means for Domino that anonymous user will be prompted for login (of course this should only be meaningful if the db has anonymous access). Another one that Domino uses is SessionID. It could be that the Login URL param is somehow confusing Domino and causing the 403 error. I would change at least that.

~Bella Fezhipiterader

Jun 12, 2012, 11:31 AM

15 Posts

Re: Xpages URL Redirection 403 error

The ID that was used to create or sign the XPage you are attempting to access may not have
sufficient rights on the server.

Ensure that the XPage is signed by an ID that, depending on the level of access that you want this user to have, is listed in either the "Sign or run unrestricted methods and operations" or "Sign agents or XPages to run on behalf of the invoker" fields (Server Document --> Security tab).

One way to test to see if insufficient rights may be causing the problem is to sign the XPages generating the error with the server's ID. The server ID should have "Sign or run unrestricted methods and operations" rights by default (with no entry in the Server Document).