They can't. There's a mapping between the thing they're requesting and the model or models that are being called, you can't access the model directly. You could access the page directly, but in most cases that won't get you anywhere, and any of the links that it points are directly controlled by the controller again, so...
Really the only thing that's available that would allow you to bypass things to any level is the XSQL and XSL files I'm using to query the database, but I don't pass the XSQL mapping through apache to tomcat, you'd be getting the XSQL and XSL files as flat files rather than as the processed versions of those. I could block that in apache, but as the XSQL files aren't in the same path as the page request it'd be a little hard to figure out where they are (and it lets me look at them quickly if I'm trying to diagnose something). There's always something that can be done to make systems more secure, but you realistically need to balance the time and effort (both to secure it and to use it), with the environment. My systems typically are installed on secure networks where all users are given fairly intense background checks. So my balance is more towards the ease of use for the end user. --mikej -=----- mike jackson [EMAIL PROTECTED] > -----Original Message----- > From: Erik Price [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 24, 2003 10:28 AM > To: Tomcat Users List > Subject: Re: INSECURE to rely on sendRedirect (??) > > > > > Mike Jackson wrote: > > Actually I use a MVC architecture, my controller has a > "standard" model for > > doing logins. So I just change the look for the login page and > change the > > configuration file a little and I'm done. Nearly 100% code > reuse (if you > > consider the relatively static login page to be code). Since > my system is > > fast and easy I haven't seen the need to branch out into new things yet. > > What happens if someone requests one of your resources directly? > > Also, I hear you -- I wasn't going to get into Filters but I read a bit > about them and the idea is actually pretty simple. And it seemed > perfect for this situation, so I just tried it. I'm pleased. > > > Erik > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
