I have developed a web application that triggers an agent from a form submission.
How do I lock the database down (ACL config?) so that anonymous (web) users can submit the form/trigger the agent but they CAN NOT open/browse the database?
Subject: Locking down a web app
“Trigger the agent” is easy – the agent should not be set to run as web user. “Submit the form” can be done fairly easily, too – give the users Depositor access, Read public documents, and make the form accessible to public users. For that matter, the form the users see doesn’t even have to be in the database – you can preview in a web browser, copy the source, then paste it onto a Page in another database or even in a non-Notes web page.
Subject: RE: Locking down a web app
Sorry, I should have been more clear.
The ‘form’ in question is an HTML form doing a POST. That is what will be triggering the agent, via anonymous web users.
Presently I have the ‘-default-’ user set to Depositor with Create Document access but I imagine that is not the best way… they can still view the inside of the database. They can’t view documents, but still… not the best.
Subject: RE: Locking down a web app
I understood completely. The user doesn’t have to access the database directly at all. The submission location is controlled by the “action=” clause of the tag, not by the storage location of the form. That means you can lock down everything except the form itself (remove the public access flags from everything else), and move the actual SERVED form to another location. (You can change the action’s URL query string from “?OpenForm&Seq=1” to “?CreateDocument” as well, if you trust your JS validation.)
Subject: RE: Locking down a web app
Okey… I think that’s what I am doing, unless I am mistaken?
The ProcessNewC agent then queries the header and gets the field values, creates a form, fills the form, saves form, etc…
Unfortunately, as it stands right now, due to -default- having Depositor with Create access, someone can paste the path and name of the DB into their browser and jump right into the main view of the DB. They can’t view documents or anything, but they can still do it, which makes me a little uncomfortable.
Subject: RE: Locking down a web app
Nope – you are directing the form to an agent. Instead, direct the form to a Form and run the agent as a WebQuerySave agent. That way the user does not need to have access to the agent or to anything that the agent touches. The user will only have access to the things you give the user access to – remove the public access flags from any design elements you don’t want the user to see.
Subject: RE: Locking down a web app
Ohh I think I understand what you mean now.
With this approach, will I have to radically modify my agents, or can they remain the same when called by WebQuerySave?
Subject: RE: Locking down a web app
The big difference is that your POST data will be available in individual document fields on the DocumentContext rather than in the Request_Content, and will already be decoded and properly data-typed for you (&parenthetical=rather+than+looking+like+this). You can still get all of the header information, but anything you POST in needs to have a corresponding field on the form.
Subject: RE: Locking down a web app
Hm… OK, I’ll have to play with this. Thanks for the info! 
Subject: RE: Locking down a web app
One more question… Is it kosher if I just make the Agent public access and remove public access from everything else?
Oddly enough I notice that I have everything already set to NO Public Access but I can still access it anonymously from a web browser??
I ask because I’m just a little hesitant to completely redesign at this point. If I must, I will… but…
JON
Subject: RE: Locking down a web app
The fact that Anonymous can see some design elements is a bit of a red herring, really, so I wouldn’t actually spend time worrying about it. (The user will get a login prompt if they actually try to do anything.) Sure, you can make the agent public access, but then you run into access problems. That’s why I prefer the WQS approach – the agent runs under the signer’s permission as a mere consequence of the user actions, rather than actually BEING a user action. Conflicting paranoias, maybe?
Subject: RE: Locking down a web app
Ah, so how I have it set up now (Default/Anonymous as Depositor with only ‘Create’ access) shouldn’t be too much of an issue, even if they can see some design elements? It is hard for me to test to see if they get prompted because all the buttons are have LotusScript methods
Subject: Locking down a web app
Jonathan
You mentioned that users can open views, although they cannot see documents. TO get around this, create a form or page called $$ViewTemplateDefault and leave it blank. This way, when anyone tries to open a view in the database (that doesn’t have its own $$ViewTemplate) then they will only get a blank screen.
Ben
Subject: RE: Locking down a web app
Good idea, thanks!
Subject: Locking down a web app
The existing suggestions will work, but they seem overly complex in my book…
I tend to have two databases – one database to hold the form, with the form’s action set to submit to an agent in database #2, which is totally locked down.
shrug Either way works…
Subject: RE: Locking down a web app
And that differs from my suggestion how? (Other than the fact that the document will never be created in the database specced in the action if the user actually has no access at all.)
Subject: RE: Locking down a web app
Simplicity, Stan. That is the difference.
And don’t run it as the web user, then it saves just fine. Just code data validation in the agent, and you are all set.
BTW, why so defensive? It was just a suggestion…