Hi, not sure if this is even a Wicket question; but drawing on the experience of the community for thoughts.
Scenario : In the Web context, <web root>/resources ;is a folder that is accessible. Lets say we manage to secure it at the Apache level not to show a blatant directory listing, however if a resource is requested by path and that resource exists you really cant block it using any Auth mechanism using Tomcat ... can you? One way, i to create a private folder somewhere and stream the resources via the App Server; however that puts additional strain on the server and architecture if you want to access those resources quickly and a lot of them; specially in a hosted environment where you have a shared instance. (No VPS and no access to Tomcat say) Not sure if there is a bridge between Apache & Tomcat say to secure a Web folder based on some cookie or jsession ids ?! ..Im thinking of creating a REST API, that encrypts urls and for all secured components in my Auth Strategy, it will generate URL's that point to a API and contains an encrypted value of the actual resource. the API decrypts the token and redirects it to the actual resource. ...Now if someone studies the redirects then they an still get to the resource, but atleast for the average person they will never be able to access the resource from the browser by seeing its location. Now is this worth the effort, .. or is there a way to secure a folder in the WAR context by some sophisticated mechanism driven by code but communicated to Apache. ..since the resources can be directly services by Apache .. am wondering how that would be possible at all. Just curious ----- Software documentation is like sex: when it is good, it is very, very good; and when it is bad, it is still better than nothing! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Securing-Resource-in-Web-Context-tp4446547p4446547.html Sent from the Users forum mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
