Kito,
I understand that solving GET would be nice. However, the GET problem
only affects GET pages with side-effects--the application developer has
control over the extent to which this affects her. The POST problem
affects every developer and is therefore more pressing and easily solved
by making the view state token cryptographically strong and choking in
restore view--in fact Trinidad and I'm sure other frameworks already do
this.
On the GET side, we have two problema--one implementation and one
controlling which pages this applies to (or doesn't apply to). I laid
out the implementation possibilities. The problem of determining when
to apply is that any page that needs to be directly accessible from
outside the application can not have this check applied to it, but JSF
doesn't currently keep track of valid external entry points.
If we don't want the application author to turn on or off individual
pages, I think we end up with either rules for when the check should be
applied. If we are specifying rules, should the rules be based purely
on the URL? If we are modifying the generated URLs, I worry some about
the performance impact of stamped actions. Even if we end up falling
back to URL manipulation for GETs, I would prefer that we use referer
checking if the referer was present in the HTTP Request that initially
created the session, as this doesn't require any URL manipulation.
-- Blake Sullivan
On 7/25/11 6:21 PM, Kito Mann wrote:
> On Mon, Jul 25, 2011 at 8:49 PM, Blake Sullivan
> <blake.sullivan_at_oracle.com <mailto:blake.sullivan_at_oracle.com>> wrote:
>
>
> As far as controlling which pages this applies to, it seems like
> kind of a pain and I would prefer that we look at ways of making
> this simpler or possibly combining with other page-level metadata
> that the application developers might wish to add.
>
>
> I really think it should be easy to turn this on -- you shouldn't have
> to earmark every page if you don't want to. The possible attacks using
> GET requests are pretty well documented, and since JSF apps have no
> restrictions on what type of actions you can perform, we can't
> guarantee that people aren't doing updates during GETs.
>
>
> -- Blake Sullivan
>
> The
> 20110707 proposal addresses this by enhancing the spec for
> getActionURL. The proposal also addresses GET based pages by
> allowing
> you to delineate which views in the app are protected and not,
> and by
> building on the form rendering such that non-protected pages
> can get to
> protected pages via GET with UIViewParameter elements.
>
> Blake, do you have some specific concerns?
>
> Ed
>
>
>