Security should be done in layers. Relying on Security by obscurity alone is bad but don't offer up more info than you need to. Typical balance of performance vs. security... In this case there is a performance impact to be extra secure. Are there holes somewhere, you bet. That is one reason for having multiple layers of security; nothing is perfectly secure but multiple layers help.
Whether tipping the MT caching scale towards the performance side is better can be debated. I appreciate this is a consideration being made by BMCsince security is an afterthought many times in software development. Jason On Tue, Jan 22, 2013 at 2:32 PM, John Baker <jba...@javasystemsolutions.com>wrote: > LJ > > "Security by obscurity". It never took off. I suspect one can enumerate > through a list of fields to see which ones exist by making calls to a Mid > Tier servlet and examining the response, but regardless, Mid Tier / AR > System will be stopping any harm coming of such calls. > > (Equally, you can make as many calls to the LoginServlet as you wish but > unless you've got a valid username/password, it's not going to let you in. > We all know a login process exists, but we're not trying to hide it.) > > I wouldn't suggest a single form, as you've got views, so ideally there's > one HTML and one JS per form/view combination, cached on disc at the Mid > Tier level. > > But as I pointed out, some server side pre-processing can add obscurity if > desired. Doug makes a good point and it can easily be addressed. > > > John > > ______________________________**______________________________** > ___________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
