Alternate to the 'Invalid SuperContainer URL' message

[BrentHedden]

Suppose I've got a URL that displays a PDF, like this -

http://10.1.1.10:8020/SuperContainer/RawData/Test?&style=noapplet+nodelete

This works fine with no problems. What I'm concerned with is if someone was to enter the following in address -

http://10.1.1.10:8020/

It presents the 'Invalid SuperContainer URL' page, which has links to the Index and Registration pages.

Is there any way to prevent this page from showing up, or having it redirect to a different page of my choosing? Since this will be on a public website, I don't want some wiseguy going in and messing things up either accidentally or intentionally by using the above example. Would using a username and password change any of this behavior?

[Smef]

There isn't a way to prevent that in stand-alone mode other than the username and password on your server. If you use the tomcat deployment option you can have a bit more control by modifying the tomcat server to handle requests for different pages through regular server configuration options.

[BrentHedden]

There isn't a way to prevent that in stand-alone mode other than the username and password on your server. If you use the tomcat deployment option you can have a bit more control by modifying the tomcat server to handle requests for different pages through regular server configuration options.

I noticed in the installation files \rootcontext\index.html which appears to be the same HTML as the page I mentioned. Although I tried to change that file, it still displayed the original message. Is there honestly no way of changing this message/page under a standalone installation? Would this be a possible feature in a future release?

Because as mentioned in the documentation, even if I put a username and password on this, an observant person could notice it, and then view and even delete other documents if they knew (or guessed) the directory name(s). Especially easy if the directory names are a sequential number.

[Smef]

Yes, if security is a concern I would not recommend using sequential paths. The stand-alone deployment is the least customizable. We may add some more cusomization features to this in the future, but for right now using a tomcat deployment would be your best option. Also, I recommend that you do not give the username and password to users you do not trust to view your documents and that you use a non-sequential number such as a UUID in your path to help with security. You can do some additional directory level security using a tomcat deployment as well, though that's a tomcat configuration thing and not really part of SuperContainer

You may want to take a look at the SuperContainer security section of the 360Works product wiki.

http://wo.360works.com/cgi-bin/support/productsupport.cgi/SuperContainer#SuperContainer50