I am having trouble with Public Access documents - I think they're set up correctly, but I still get asked for credentials!
I have developed a system that receives XML information posted to an Agent. This agent must access an XSLT file, which in order to avoid having it on both my development & live servers in the file system, I have implemented as a Page. In order that the Agent can access it, this Page is marked as 'Available to Public Access users', & works just fine.
However, having just tied down the ACL before rolling it out into production, I was reminded that the Agent also needs to access one of the documents imported from the XML (the agent transforms the XML into DXL using this XSLT, then imports the resulting XML as NotesDocuments). I have a special view with a Form Formula, that opens the aforementioned document in a form which shows the XML response. Currently, the agent reads in the XML from this document via the view, then prints it to the posting client. However, like the XSLT file, the server agent needs to access this document anonymously, so I have set the 'Available to Public Access users' property on the View & the XML form, & I have created a Computed for Display field on the XML form called $PublicAccess, with "1" as its value. As this didn't work, I have even tried changing this field to a Computed field, & moving it to the form the document was originally created using, so the document itself has a permanent $PublicAccess="1" field, & the agent still returns nothing, & sure enough, when opening the URL with my browser, I get a login box.
So, what am I missing with this Public Access thing? I don't want to allow the whole database to be open to anonymous users, as it contains orders for a client. Even though nobody will know the exact URLs to find the order information, & I could simply put redirects on any obvious URLs, this doesn't seem like a secure solution! I appreciate that if it was working as I intended, then the XML response to the orders would be available to anonymous users, but I don't see this as too much of an issue, as they are only available via URLs like this: http://server/database/(Responses)/Q1W2E3R4T5Y6U7I88025715C005AEE25, & it has to better than having a browsable database open to all!
Thanks.
However, having just tied down the ACL before rolling it out into production, I was reminded that the Agent also needs to access one of the documents imported from the XML (the agent transforms the XML into DXL using this XSLT, then imports the resulting XML as NotesDocuments). I have a special view with a Form Formula, that opens the aforementioned document in a form which shows the XML response. Currently, the agent reads in the XML from this document via the view, then prints it to the posting client. However, like the XSLT file, the server agent needs to access this document anonymously, so I have set the 'Available to Public Access users' property on the View & the XML form, & I have created a Computed for Display field on the XML form called $PublicAccess, with "1" as its value. As this didn't work, I have even tried changing this field to a Computed field, & moving it to the form the document was originally created using, so the document itself has a permanent $PublicAccess="1" field, & the agent still returns nothing, & sure enough, when opening the URL with my browser, I get a login box.
So, what am I missing with this Public Access thing? I don't want to allow the whole database to be open to anonymous users, as it contains orders for a client. Even though nobody will know the exact URLs to find the order information, & I could simply put redirects on any obvious URLs, this doesn't seem like a secure solution! I appreciate that if it was working as I intended, then the XML response to the orders would be available to anonymous users, but I don't see this as too much of an issue, as they are only available via URLs like this: http://server/database/(Responses)/Q1W2E3R4T5Y6U7I88025715C005AEE25, & it has to better than having a browsable database open to all!
Thanks.
Sjef Bosman
Is the form also Public Access? Form Properties, last tab, at the bottom?
ASKER
Yes, sorry it is. That is, the XML form, not the form originally used - which did you mean?
I've just changed the original form now, & I'll try again, although this was only a workaround to see why it wasn't working. Am I right in thinking that a Computer for Display $PublicAccess="1" field on the form I am using to view the document should be sufficient?
Thanks.
I've just changed the original form now, & I'll try again, although this was only a workaround to see why it wasn't working. Am I right in thinking that a Computer for Display $PublicAccess="1" field on the form I am using to view the document should be sufficient?
Thanks.
$PublicAccess should be in the document, to indicate that the document can be opened by anyone. A CfD-field in the form is useless.
Do you have Readers-fields in the document as well, that could block the user from seeing the data? What's the error message you get? What's in the log.nsf on the server?
Do you have Readers-fields in the document as well, that could block the user from seeing the data? What's the error message you get? What's in the log.nsf on the server?
ASKER
Setting the original form (& the form being used to display the document) as Available to Public Access users had no effect.
So it's no use having a Computed for Display $PublicAccess="1" field on the form I am using.
So how can I make this document only available to Public Access users when viewed through this particular form?
And more importantly, why can't I see it without loggin in via any form?
There are no Readers fields in the document at all, so that shouldn't be preventing access. I don't get an error message, just a login box, when I try to open the URL myself with a browser. When my Agent tries, it simply returns nothing at all, sending a blank response to the posting client system.
So Available to Public Access users should work if:
(i) The Form originally used to create the document has that property set on the security tab of the infobox
(ii) The Form being used to view the document (via a form formula in the view) also has that property set
(iii) The document has a $PublicAccess="1" field, which cannot be Computed for Display (i thought they were as good as computed as long as the document is opened)
(iv) The View via which you are accessing the document also has the property set
All of these things are in place, yet still I am asked to login.
Is there anything I need to do?
Thanks
So it's no use having a Computed for Display $PublicAccess="1" field on the form I am using.
So how can I make this document only available to Public Access users when viewed through this particular form?
And more importantly, why can't I see it without loggin in via any form?
There are no Readers fields in the document at all, so that shouldn't be preventing access. I don't get an error message, just a login box, when I try to open the URL myself with a browser. When my Agent tries, it simply returns nothing at all, sending a blank response to the posting client system.
So Available to Public Access users should work if:
(i) The Form originally used to create the document has that property set on the security tab of the infobox
(ii) The Form being used to view the document (via a form formula in the view) also has that property set
(iii) The document has a $PublicAccess="1" field, which cannot be Computed for Display (i thought they were as good as computed as long as the document is opened)
(iv) The View via which you are accessing the document also has the property set
All of these things are in place, yet still I am asked to login.
Is there anything I need to do?
Thanks
The database value for the signer of the agent(?) should be no access, but allow to read and write public access documents - then it is anonymous, or the role of depositor?. Also, there needs to be one public access view that has the form in it.
I've done both (without using the $publicAccess) field. If all the user(agent) needs to do is deposit an anonymous document, then the form need the anonymous parameter checked, and the users(agent signer) needs to have either a "No Access" with ability to read and write or just write public documents, or the role of depositor.
In employee survey applications, I made */myou/myo = depositor, write public documents, and checked the anonymous form property.
I've done both (without using the $publicAccess) field. If all the user(agent) needs to do is deposit an anonymous document, then the form need the anonymous parameter checked, and the users(agent signer) needs to have either a "No Access" with ability to read and write or just write public documents, or the role of depositor.
In employee survey applications, I made */myou/myo = depositor, write public documents, and checked the anonymous form property.
(i) the form: okay, but not necessary I think
(ii) the form to display: okay (this makes the form accessible)
(ii) document has $PublicAccess set to "1": okay (this makes the document itself accessible!)
(iv) the view: okay (view accessible)
Any framesets that are opened? Is there a user Anonymous in the ACL of the database?
(ii) the form to display: okay (this makes the form accessible)
(ii) document has $PublicAccess set to "1": okay (this makes the document itself accessible!)
(iv) the view: okay (view accessible)
Any framesets that are opened? Is there a user Anonymous in the ACL of the database?
ASKER
marilyng:
The database value for the signer of the agent(?) should be no access, but allow to read and write public access documents - then it is anonymous, or the role of depositor? - sorry, I don't understand. The Agent has been signed by me, & I have Manager Access with all options ticked, but how is that relevant? The Agent is set to run on behalf of the server, however, which I've just realised is probably why it doesn't work at all on my other server! :-) Anyway, the LotusScript in the agent tries to access a document via http via this view with a form formula, which shows an alternative view of the document (XML). It is access to this document, either from the agent or from a web browser, that I am having trouble with. It did work until I changed Default=Reader to Default=No Access in the ACL.
sjef_bosman:
So you agree that I shouldn't need the Public Access property set on the original form, just on the XML form I'm using to display the document. But I do need the property set on the display form, & the $PublicAccess="1" field on the document, & the View must also have the property set. This all makes sense, & is how I thought it needed to be. And there are no framesets at all in use here.
So you think it should work?
Thanks.
The database value for the signer of the agent(?) should be no access, but allow to read and write public access documents - then it is anonymous, or the role of depositor? - sorry, I don't understand. The Agent has been signed by me, & I have Manager Access with all options ticked, but how is that relevant? The Agent is set to run on behalf of the server, however, which I've just realised is probably why it doesn't work at all on my other server! :-) Anyway, the LotusScript in the agent tries to access a document via http via this view with a form formula, which shows an alternative view of the document (XML). It is access to this document, either from the agent or from a web browser, that I am having trouble with. It did work until I changed Default=Reader to Default=No Access in the ACL.
sjef_bosman:
So you agree that I shouldn't need the Public Access property set on the original form, just on the XML form I'm using to display the document. But I do need the property set on the display form, & the $PublicAccess="1" field on the document, & the View must also have the property set. This all makes sense, & is how I thought it needed to be. And there are no framesets at all in use here.
So you think it should work?
Thanks.
I know it can work, I have a similar database. You are just trying with thwe URL you gave:
http: //server.xyz/database/(Res
and the (Responses) view is set for Public Access?
One thing: can you try to restart the HTTP task on the server? Or Refresh?
http: //server.xyz/database/(Res
and the (Responses) view is set for Public Access?
One thing: can you try to restart the HTTP task on the server? Or Refresh?
ASKER
I've restarted the server numerous times. And the Responses is XML Responses, not Notes Responses, not that it really matters I suppose.
So everything that should have PublicAccess set has, and yet still it prompts for a login. Everything's running R6.5, although we're about to upgrade to 7.x any time soon. Anyone know if it's a version issue? Or got anything else I can try?
Thanks.
So everything that should have PublicAccess set has, and yet still it prompts for a login. Everything's running R6.5, although we're about to upgrade to 7.x any time soon. Anyone know if it's a version issue? Or got anything else I can try?
Thanks.
Ok two steps, including the ACL steps sjef suggested
First Server side:
For more information, see Anonymous Internet/intranet access.
1. From the Domino Administrator, click the Configuration tab, and open the Server document.
2. Click the Security tab.
3. In the Security Settings section, enable "Allow anonymous Notes connections."
4. Save the document.
5. Create an entry named Anonymous in the ACL of all databases to which you want to allow anonymous access. Assign the appropriate access level -- typically Reader access. If you don't add Anonymous as an entry in the ACL, anonymous users and servers get -Default- access.
6. Stop and restart the server so that the changes take effect.
---------------- The ACL on the DATABASE
Read public documents
Select this privilege to allow users who have No Access or Depositor access to read documents or to see views and folders to which the designer assigned the property "Available to Public Access users." The form must contain a text field named $PublicAccess, and its value should be equal to 1.
Write public documents
Select this privilege to allow users to create and edit specific documents that are controlled by forms to which the designer has assigned the property "Available to Public Access users." This option lets you give users create and edit access to specific documents without giving them Author access. Author access, or an equivalent role, gives users access to create documents from any form in a database.
Note Users who have this privilege can also delete any public documents in the database.
First Server side:
For more information, see Anonymous Internet/intranet access.
1. From the Domino Administrator, click the Configuration tab, and open the Server document.
2. Click the Security tab.
3. In the Security Settings section, enable "Allow anonymous Notes connections."
4. Save the document.
5. Create an entry named Anonymous in the ACL of all databases to which you want to allow anonymous access. Assign the appropriate access level -- typically Reader access. If you don't add Anonymous as an entry in the ACL, anonymous users and servers get -Default- access.
6. Stop and restart the server so that the changes take effect.
---------------- The ACL on the DATABASE
Read public documents
Select this privilege to allow users who have No Access or Depositor access to read documents or to see views and folders to which the designer assigned the property "Available to Public Access users." The form must contain a text field named $PublicAccess, and its value should be equal to 1.
Write public documents
Select this privilege to allow users to create and edit specific documents that are controlled by forms to which the designer has assigned the property "Available to Public Access users." This option lets you give users create and edit access to specific documents without giving them Author access. Author access, or an equivalent role, gives users access to create documents from any form in a database.
Note Users who have this privilege can also delete any public documents in the database.
> 3. In the Security Settings section, enable "Allow anonymous Notes connections."
Anonymous NOTES connections?? That's for Notes clients, AFAIK, not for web clients!
Anonymous NOTES connections?? That's for Notes clients, AFAIK, not for web clients!
Direct quote from Administrator help, don't shoot the messenger.
ASKER
I don't need to allow anonymous Notes connections, only anonymous web connections.
Still doesn't work??
Same thing, I think.. try and see what happens.
ASKER
Still doesn't work! :-(
I've just been through & double-checked everytyhing today, to make sure I missed nothing. The Document, the normal Form & the two XML Forms, the View & the Page - they're all set to be 'Available to Public Access users'. It SHOULD be working.
I think for now I will have to open up the ACL so it works again, & come back to this - I need to work on other parts of the project to get it finished, so I can't waste any more time on this right now. I'm not happy about the ACL being open though, so any more thoughts on what could be wrong would be very much appreciated.
Strangely enough, the Page (which I am using to provide the XSLT stylesheet to convert into DXL) works just fine.
Thanks for your assistance.
I've just been through & double-checked everytyhing today, to make sure I missed nothing. The Document, the normal Form & the two XML Forms, the View & the Page - they're all set to be 'Available to Public Access users'. It SHOULD be working.
I think for now I will have to open up the ACL so it works again, & come back to this - I need to work on other parts of the project to get it finished, so I can't waste any more time on this right now. I'm not happy about the ACL being open though, so any more thoughts on what could be wrong would be very much appreciated.
Strangely enough, the Page (which I am using to provide the XSLT stylesheet to convert into DXL) works just fine.
Thanks for your assistance.
All of these things are in place, yet still I am asked to login << what is asking? is it the Notes Login Box or the Network Login?
So, when you type in the http://servername/mail/mymail.nsf, you get a login request and having done that, your mail file.
When you type in Http://servername/thisanonymousdb.nsf, if you're getting a login request from Notes, it's because the server is set not to allow anonymous connections. If you get it from the network, then the firewall is set to put the server behind a DMZ, rather than in front, so the firewall and network configuration is what might be denying anonymous connections to the server. understandable.
So, when you type in the http://servername/mail/mymail.nsf, you get a login request and having done that, your mail file.
When you type in Http://servername/thisanonymousdb.nsf, if you're getting a login request from Notes, it's because the server is set not to allow anonymous connections. If you get it from the network, then the firewall is set to put the server behind a DMZ, rather than in front, so the firewall and network configuration is what might be denying anonymous connections to the server. understandable.
ASKER
marilyng:
It is the Domino Server asking for login credentials. And it isn't set not to allow anonymous connections, as the XSLT file I have implemented as a Page, used to convert the incoming XML into DXL, works fine at http://server/path/database/BizTalk2DXL.xsl - this page opens up anonymously.
Interestingly, I just tried unsetting the abovementioned Page's 'Available to Public Access users' property, so I could see it start asking for a login - it doesn't! Despite having un-set the property, restarted HTTP & even after a DBCache Flush! Presumably at some point, it would wake up & notice the change - but I've put it back for now.
I've also just tried upping the Default ACL level - as predicted, if Reader or above, it lets you see the document, if No Access or Depositor, it prompts for login.
It is the Domino Server asking for login credentials. And it isn't set not to allow anonymous connections, as the XSLT file I have implemented as a Page, used to convert the incoming XML into DXL, works fine at http://server/path/database/BizTalk2DXL.xsl - this page opens up anonymously.
Interestingly, I just tried unsetting the abovementioned Page's 'Available to Public Access users' property, so I could see it start asking for a login - it doesn't! Despite having un-set the property, restarted HTTP & even after a DBCache Flush! Presumably at some point, it would wake up & notice the change - but I've put it back for now.
I've also just tried upping the Default ACL level - as predicted, if Reader or above, it lets you see the document, if No Access or Depositor, it prompts for login.
Ok, caught me in the middle of upgrading my server..
Go to server document, port configuration:
(HTTP/HTTPS)
TCP/IP port number: 80
TCP/IP port status: Enabled
Enforce server access settings: No
Authentication options:
Name & password: Yes
Anonymous: Yes
Go to server document, port configuration:
(HTTP/HTTPS)
TCP/IP port number: 80
TCP/IP port status: Enabled
Enforce server access settings: No
Authentication options:
Name & password: Yes
Anonymous: Yes
Ah, good one! Btw, if you have an Internet Site document, you'd have to go there to find these settings.
ASKER
I do indeed use Internet Site documents on my servers, & the relevant one has:
Anonymous: Yes
Name & password: Yes
I'm still flummoxed by this.
Anonymous: Yes
Name & password: Yes
I'm still flummoxed by this.
Is it a large database? If not, can you prepare a test-copy of it, with the ACL as is, and some documents, and send me/us a copy? That way, we could see all settings in the database itself.
Btw flummoxed = flabbergasted?
Btw flummoxed = flabbergasted?
Yeowee..! hey, replication cures all evils. Throw a new replica. (pant, pant, grasping at straws...) if that doesn't work, try throwing a new copy. Maybe the server is caching its settings... do you have any other anonymous databases that work?
Maybe you could try to create from scratch a very simple database, one form, one document, one view, that should be displayed for an anonymous user?
ASKER
sjef_bosman:
It's not large, but I wouldn't be able to share it as it would be too hard to hide who it was for.
And yes, flummoxed = flabbergasted:
flum·mox (flŭm'əks)
tr.v. Informal., -moxed, -mox·ing, -mox·es.
To confuse; perplex.
marilyng:
I agree that creating a new replica can often just fix weird issues with Notes database - however, in this case, I have two replcas on different servers, & they both behave identically, so I don't believe it will help.
everyone:
I've had to leave this project for a few days now, as the party that sends the information is unavailable. When I come back to it, I will try creating a new replica of the database, followed by building up a new database, to see if I can get it to work as we believe it should.
This is likely to be next week now, however, so watch this space.
Thanks for your help.
It's not large, but I wouldn't be able to share it as it would be too hard to hide who it was for.
And yes, flummoxed = flabbergasted:
flum·mox (flŭm'əks)
tr.v. Informal., -moxed, -mox·ing, -mox·es.
To confuse; perplex.
marilyng:
I agree that creating a new replica can often just fix weird issues with Notes database - however, in this case, I have two replcas on different servers, & they both behave identically, so I don't believe it will help.
everyone:
I've had to leave this project for a few days now, as the party that sends the information is unavailable. When I come back to it, I will try creating a new replica of the database, followed by building up a new database, to see if I can get it to work as we believe it should.
This is likely to be next week now, however, so watch this space.
Thanks for your help.
ASKER
Okay, we never found a resolution, & if I decide to progress it further, I'll start a new question.
Thanks.
Thanks.
> Maybe you could try to create from scratch a very simple database
What came out of that exercise?? Or you never tried?
What came out of that exercise?? Or you never tried?
ASKER
Never really got round to it. Have to start a new question soon & get to the bottom of it.
ASKER
That's fine, we never really sorted it out.
Thanks.
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.