My opinion to use existing viewState parameter comes from frameworks
internals; adding one more hidden parameter could break some existing
libraries that relays on javax.faces.ViewState ( the only required by
current spec ), so that's matter of backward compatibility.
Fo GETJSF 2 already has appropriate "view parameter" that can be used
to check secure token. It can be special Validator or component that
extends UIViewParam ( or coming UIViewAction ? ) and blocks access to
page without proper token. Everything already there to implement such
protection and make it configurable per page.
On Mon, Jul 25, 2011 at 6:43 PM, Blake Sullivan
<blake.sullivan_at_oracle.com> wrote:
> 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>
> 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
>>>
>>
>
>
>
--
_________________
entia non sunt multiplicanda praeter necessitatem,
(entities should not be multiplied beyond necessity.)