:-) I assume this is done in Spring web flow (I'm not much of a Java/Spring/... webapp developer)? In case I have to change it, hints as to where?
My thinking (and some experience so far) is the lion's share of access by CAS client software directly configured to use e.g. /cas/login and /cas/serviceValidate, that people/... hitting the (context) root with the intent of performing an out-of-band login are the exception rather than the rule, and that anything else is some one/thing who shouldn't be there. Thanks. Tom. On 08/30/2013 10:49 AM, Scott Battaglia wrote: > Then we are succeeding if we're even confusing security! :-) > > You should be able to configure it however you'd like. From a user > perspective though, if someone hits the wrong page, with an application > the size of CAS, there's a very high likelihood they meant to go to the > login page anyway. Other than services management there is only one > publicly facing URL. > > > On Fri, Aug 30, 2013 at 1:09 PM, Tom Poage <[email protected] > <mailto:[email protected]>> wrote: > > It seems CAS has longstanding behavior to redirect requests for > non-existing content to /cas/login vs. issue a 404. > > Curious, is there a security/design/... reason for doing so? > > The basis of the question is an observation by one of our security > team that it throws off scanning software we use. > > Thanks. > Tom. > -- > You are currently subscribed to [email protected] > <mailto:[email protected]> as: [email protected] > <mailto:[email protected]> > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
