.
Original message
Date: Wed, 12 Oct 2005 15:57:59 -0400
From: Mike Kienenberger [EMAIL PROTECTED]
Subject: Re: t:saveState server/client ... or
request/session
To: MyFaces Discussion users@myfaces.apache.org,
[EMAIL PROTECTED]
Werner,
We're talking about encryption of the client state data
there is
only a small chunk of data needing to be hidden.
Original message
Date: Wed, 12 Oct 2005 22:02:39 +0200
From: Werner Punz [EMAIL PROTECTED]
Subject: Re: t:saveState server/client ... or
request/session
To: users@myfaces.apache.org
Ok sorry did not think of that anymore
be? .properties, DD, faces-config ? I really don't care ;)
Original message
Date: Tue, 11 Oct 2005 16:29:21 -0400
From: Mike Kienenberger [EMAIL PROTECTED]
Subject: Re: t:saveState server/client ... or
request/session
To: MyFaces Discussion users@myfaces.apache.org
Hey Dennis
Saving the key in each session might work. The environment
may
preserve server-side sessions across restarts, depending on
the
configuration.
Yes, and javax.crypto.spec.SecretKeySpec implements
Serializable. There are of course risks w/ a key being
stored in serialized sessions.
I'd also
Yeah, that's a good point. I'm going to enhance whatever you come up
with to add the ip address into the state and validation. Maybe you
can leave in a hook for adding other authentication info into the
mix. Or I suppose I can create my own delegating StateManager to do
it. Might be better
Good, I'll just email it to your gmail account before I even
open the issue.
Original message
Date: Wed, 12 Oct 2005 14:51:38 -0400
From: Mike Kienenberger [EMAIL PROTECTED]
Subject: Re: t:saveState server/client ... or
request/session
To: MyFaces Discussion users
: Mike Kienenberger [EMAIL PROTECTED]
Subject: Re: t:saveState server/client ... or
request/session
To: MyFaces Discussion users@myfaces.apache.org
Yeah, that's a good point. I'm going to enhance whatever
you come up
with to add the ip address into the state and validation.
Maybe you
can
Hmmm ... I was not aware of this secret gathering. I'm
dennisbyrne for sf.
Original message
Date: Wed, 12 Oct 2005 15:19:04 -0400
From: Mike Kienenberger [EMAIL PROTECTED]
Subject: Re: t:saveState server/client ... or
request/session
To: MyFaces Discussion users
I do not think encryption is that important, signing probably yes,
but if you want encryption you always can switch to a ssl layer which
is easier to handle.
Mike Kienenberger wrote:
I did a search on the JSF 1.2 spec, and the four references to
encrypting are all vague and general (It is
Werner,
We're talking about encryption of the client state data at the client,
not of the data channel between the client and the server. Right now,
an end-user can do a view-source, then Base64 decode the state tree
field to see all stored data. Depending on what the application is
doing,
: t:saveState server/client ... or
request/session
To: users@myfaces.apache.org
Ok sorry did not think of that anymore, understandable after
13 hours of coding ;-)
Werner
Mike Kienenberger wrote:
Werner,
We're talking about encryption of the client state data at
the client,
not of the data channel
in my project over a week or two, are you
interested?
Original message
Date: Wed, 5 Oct 2005 09:30:21 +0200
From: Martin Marinschek [EMAIL PROTECTED]
Subject: Re: t:saveState server/client ... or
request/session
To: MyFaces Discussion users@myfaces.apache.org
Ok,
to shed some
, faces-config ? I really don't care ;)
Original message
Date: Tue, 11 Oct 2005 16:29:21 -0400
From: Mike Kienenberger [EMAIL PROTECTED]
Subject: Re: t:saveState server/client ... or
request/session
To: MyFaces Discussion users@myfaces.apache.org
Hey Dennis,
Rather than try
in my project over a week or two, are you
interested?
Original message
Date: Wed, 5 Oct 2005 09:30:21 +0200
From: Martin Marinschek [EMAIL PROTECTED]
Subject: Re: t:saveState server/client ... or
request/session
To: MyFaces Discussion users@myfaces.apache.org
Ok,
to shed some light
Ok,
to shed some light on this:
- in the JSF RI, there is encryption on the client side - we have not
implemented it so far, (this was after 1.1) cause we have no one here
with too much time and experience in this. It should be not too hard
though with the RI as an example and the java security
Martin Marinschek wrote:
Ok,
to shed some light on this:
Thanks for all the info!
- in the JSF RI, there is encryption on the client side - we have not
implemented it so far, (this was after 1.1) cause we have no one here
with too much time and experience in this. It should be not too hard
You may not use it as a reference, but as an example!
regards,
Martin
On 10/5/05, Simon Kitching [EMAIL PROTECTED] wrote:
Martin Marinschek wrote:
Ok,
to shed some light on this:
Thanks for all the info!
- in the JSF RI, there is encryption on the client side - we have not
Regarding subtle differences when changing
javax.faces.STATE_SAVING_METHOD to 'server' vs. 'client' .
These differences appear to be forcing me to choose between
two requirements : producing an application w/ 'context
complete' requests and producing an app that is secure.
With 'client' side
Dennis Byrne wrote:
Regarding subtle differences when changing
javax.faces.STATE_SAVING_METHOD to 'server' vs. 'client' .
These differences appear to be forcing me to choose between
two requirements : producing an application w/ 'context
complete' requests and producing an app that is secure.
I guess it would be possible to implement a custom
state-saving/state-restoring mechanism that encrypts the
data using a
key stored in the user session.
... or use a converter that did the encryption/decryption ?
Why would the objects stored in the user session on the
server be
serialized
20 matches
Mail list logo
