You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship" <hl...@comcast.net> on 2005/11/27 21:58:40 UTC
Forms in 4.1
Thought I'd take a moment out from packing my house to describe what I'd
like to do in 4.1.
Basically, I want to effectively eliminate the rewind cycle. No more
false rendering.
There's going to be a new kind of interaction between the enclosing Form
and the form control components, including For.
As components render, they will register a submit-time callback. The
callback identifies the component (i.e., ComponentAddress) and allows an
additional arbitrary object to be stored as well. Somehow, integrated
into this, will be code in the Form to re-tell the fields what their
element name is. In other words, new method on IFormComponent and IForm.
When a form is triggered, it will no longer render itself; instead it
will use the serialized stream to perform callbacks that reflect the
order in which the fields rendered in the first place.
For and Table will be extended to provide a series of response-time
callbacks during the render, that will be used to restore page state
just before form control components are invoked using callbacks. In
fact, there will probably be a new interface to describe the
relationship between components like For and Foreach and the Form, as
neither will need to have a client-side element id (or generate any
hidden form fields).
This is actually a much simpler design than what's present in 3.0 and
4.0 in many ways; it reflects my growing confidence in what has evolved
out of the DataSqueezer. Further, the reason I felt so strongly about
removing the (ill concieved) Action service was because maintaining that
would prevent this evolution in the Form component.
Things will still work for a volatile For within a Form ... though there
are less guarantees than that the proper objects will be updated. I
suspect that volatile For's will still register callbacks with the Form
for each iteration, but the callback will be a bit different.
Alternately, volatile For components will have no interaction with the
enclosing Form. Still puzzling that out.
If components will no longer need any interaction with the enclosing Form.
It does mean that there'll be a large, MIME encoded object stream for
every form, as a hidden form field. But much of the other logic will go
away. I believe that there will no longer be the possibility of a
StaleLinkException. The situations that may cause StaleLinkExceptions
today may cause NPEs under this scheme.
You can imagine that this object stream would look something like:
<span jwcid="for">
<input jwcid="name"/> <input jwcid="age"/>
</span>
MyPage/for callback <DecodePrimaryKey <Integer 10001>>
MyPage/name callback <UpdateFromParameter 'name'>
MyPage/age callback <UpdateFormParameter 'age'>
MyPage/for callback <DecodePrimaryKey <Integer 12020>>
MyPage/name callback <UpdateFromParameter 'name_0'>
MyPage/age callback <UpdateFormParameter 'age_0'>
etc.
In addition, it will become much less possible to "predict" what the
hidden form fields for a Form component will look like, from a unit
testing angle. The current XML based integration tests will become
impossible to maintain. For my day contract, I'm starting to look a
jWebUnit ... I hope to find a way to merge jWebUnit tests with
Tapestry's mock servlet container. That would be an optimum solution!
I would guess there would be a small performance hit for trivial forms,
but as a form grows in complexity, the advantages of this 4.1 scheme
would grow. This is largely because there would be a single object
stream -> MIME conversion (with all that overhead, including gzip
compression) vs. many small ones (for each value iterated by a For, etc.).
It's funny how, as Tapestry advances, I'm finding it easier and better
to store MORE state on the client than on the server! Although I have
been doing some thinking about a WebObjects style state management
(effectively, a tree of page states for each page), I'm seeing less
urgency in the need for that given the existence of DataSqueezer and
MB's IPrimaryKeyConverter.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Re: Forms in 4.1
Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard M. Lewis Ship <hlship <at> comcast.net> writes:
> Basically, I want to effectively eliminate the rewind cycle. No more
> false rendering.
This is probably a silly question, but why woud you like to eliminate
the rewind cycle? Or rather, what problem are you trying to solve?
> As components render, they will register a submit-time callback. The
> callback identifies the component (i.e., ComponentAddress) and allows an
> additional arbitrary object to be stored as well. Somehow, integrated
> into this, will be code in the Form to re-tell the fields what their
> element name is. In other words, new method on IFormComponent and IForm.
It sounds like a DirectLink. Why not store the field name in that
arbitrary object and let the form field (if it is one) extract
it without bothering the Form? Then the Form is only responsible
for deseralizing the callbacks and then call them without having
to deal with the differences between form field components (eg,
TextField) and non-form field components (eg, For).
If I understand your proposed solution correctly, it may have an
interesting effect on how a FieldLabel may work. It can find a way
to register its callback after the form field component registers
its.
> I suspect that volatile For's will still register callbacks with the Form
> for each iteration, but the callback will be a bit different.
To check for errors?
> If components will no longer need any interaction with the enclosing Form.
I see this is a benefit of the proposed solution. Are there others?
> I believe that there will no longer be the possibility of a
> StaleLinkException. The situations that may cause StaleLinkExceptions
> today may cause NPEs under this scheme.
The For and If components are already taking care of that today.
Am I missing something?
> For my day contract, I'm starting to look a
> jWebUnit ... I hope to find a way to merge jWebUnit tests with
> Tapestry's mock servlet container. That would be an optimum solution!
I am with Jesse here: I'd also recommend HtmlUnit over HttpUnit (or
a derivative like jWebUnit). Its code is cleaner and its developers
are much more responsive.
I've been using it to unit test my pages with fair success. The only
wish I have is to be able to run the app and Tapestry code in the
same process of the client. This will allow JUnit's AssertionFailedError
to go back to the JUnit Test Runner which can then show the location of
the failure clearly. Now it will be caught by Tapestry and return an
Exception page to the test client and the location info is lost.
I'm sure it is possible to run the HtmlUnit WebClient in the same
process as the server because that's how the unit tests for HtmlUnit
itself are executed.
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
I think he has a point in that Tapestry needs a stable release.
Now, all of the major architectural concerns *have* to be addressed,
IMO, before we even consider going that kind of long-term stability (the
use of abstract classes, the rewind cycle, etc).
By the way, is it possible to split Tapestry's development in
tapestry-core and tapestry-components and remove the contrib project? I
think Tapestry could benefit of a component base consolidation along
with the architectural changes, and those can be done in separate
sub-projects, don't you think ??
As for stabilization, I mostly think Tapestry is suffering from some
disorganization (growing pains I guess) that could be solved by using
JIRA to plan releases an such.
Just my 2 cents..
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Cliff Zhao wrote:
> IMHO, from a user perspective, to let more users accept Tapestry, Tapestry
> should consider more for the users. Compatibility and the ease of upgrade
> should be a high priority. Tapestry should build a kernel that lasts over
> time. Drastic changes from release to release will drive users away. A large
> user base and community is very important for an enterprise user. I like
> Tapestry but as a architect in a big company, I may have to reconsider my
> choice if Tapestry can not reach a stable stage within six months. Every
> upgrade is a non-trivial cost for an SEI CMM level 3 organization that is
> targeting CMMI level 5 certification.
> For me, it's more important to have a stable, well optimized and well
> documented Tapestry.
>
> Best Regards,
> Cliff Zhao
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Cliff Zhao <zh...@gmail.com>.
IMHO, from a user perspective, to let more users accept Tapestry, Tapestry
should consider more for the users. Compatibility and the ease of upgrade
should be a high priority. Tapestry should build a kernel that lasts over
time. Drastic changes from release to release will drive users away. A large
user base and community is very important for an enterprise user. I like
Tapestry but as a architect in a big company, I may have to reconsider my
choice if Tapestry can not reach a stable stage within six months. Every
upgrade is a non-trivial cost for an SEI CMM level 3 organization that is
targeting CMMI level 5 certification.
For me, it's more important to have a stable, well optimized and well
documented Tapestry.
Best Regards,
Cliff Zhao
On 11/28/05, Davor Hrg <hr...@gmail.com> wrote:
>
> I'm no expert in .NET bu have seen aplications killed with VIEWSTATE,
> one page had a viewstate of 75 kB, which means 150 kB of traffic per
> request.
>
> I'm affraid this could break the "easiest way should be the right way".
>
> I hope someone with more .NET expirience could elaborate more on the
> VIEWSTATE issue.
>
> On 11/28/05, Danny Angus <Da...@slc.co.uk> wrote:
> >
> > Massimo Lusetti wrote:
> >
> > >I've to admit, as a global note, I'm not very comfortable with storing
> > > states (and consequently what relates to states) on the client
> >
> > I agree with Massimo, not only does bandwidth become an issue, but
> > security
> > becomes more of an issue as well.
> >
> > I'm not saying that it would necessarily expose a weakness, but it might
> > make it easier for less-experienced developers to inadvertently expose a
> > weakness.
> >
> > For example if it is possible to manipulate the client-side state, and
> we
> > have to assume that if we can do it then it is possible (if difficult),
> so
> > we have to ensure that every precaution is taken to ensure that we
> > validate
> > the state against allowable states for that user. In practice this is
> not
> > trivial, we have to identify the appropriate validation to use for each
> > application and set of data. The real danger of this is that we really
> > would be seeing a move to a less secure model.
> >
> > Lets look at an example; If the state recorded is an account number for
> an
> > account you are allowed to administer we can let you see your account
> > details, but how can be be sure that you are still the person who is
> > entitled to see that data? Obvious we make you log in (and http_auth
> > ensures that the browser sends your password with every logged-in
> request)
> > and compare the user we retrieve from the server with the one associated
> > with the client-side state, in our example we also have to verify that
> the
> > account is associated with a user you are allowed to administer. We will
> > pretty quickly end up wishing that we had a server-side state we could
> use
> > to validate requests against. Doesn't this defeat the purpose? I though
> > that the whole principle behind sessions and session-id's was about
> moving
> > state from the client into the server where it is secure and can't be
> > tampered with.
> > Is it not possible to split the state intellignently between client and
> > server?
> >
> > As far as bandwidth is concerned I'm quite sure that my employer would
> be
> > somewhat less than pleased if my new application consumed more bandwidth
> > than an equivalent older one, someone has to pay for bandwidth and its
> > often both parties, naievely put for a 100% marginal rise in traffic
> > between two parties you get a 200% rise in marginal cost.
> >
> > d.
> >
> >
> >
> >
> ***************************************************************************
> > The information in this e-mail is confidential and for use by the
> > addressee(s) only. If you are not the intended recipient (or responsible
> for
> > delivery of the message to the intended recipient) please notify us
> > immediately on 0141 306 2050 and delete the message from your computer.
> You
> > may not copy or forward it or use or disclose its contents to any other
> > person. As Internet communications are capable of data corruption
> Student
> > Loans Company Limited does not accept any responsibility for changes
> made
> > to this message after it was sent. For this reason it may be
> inappropriate
> > to rely on advice or opinions contained in an e-mail without obtaining
> > written confirmation of it. Neither Student Loans Company Limited or the
> > sender accepts any liability or responsibility for viruses as it is your
> > responsibility to scan attachments (if any). Opinions and views
> expressed in
> > this e-mail are those of the sender and may not reflect the opinions and
> > views of The Student Loans Company Limit
> > ed.
> >
> > This footnote also confirms that this email message has been swept for
> the
> > presence of computer viruses.
> >
> >
> **************************************************************************
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
Re: Forms in 4.1
Posted by Davor Hrg <hr...@gmail.com>.
I'm no expert in .NET bu have seen aplications killed with VIEWSTATE,
one page had a viewstate of 75 kB, which means 150 kB of traffic per
request.
I'm affraid this could break the "easiest way should be the right way".
I hope someone with more .NET expirience could elaborate more on the
VIEWSTATE issue.
On 11/28/05, Danny Angus <Da...@slc.co.uk> wrote:
>
> Massimo Lusetti wrote:
>
> >I've to admit, as a global note, I'm not very comfortable with storing
> > states (and consequently what relates to states) on the client
>
> I agree with Massimo, not only does bandwidth become an issue, but
> security
> becomes more of an issue as well.
>
> I'm not saying that it would necessarily expose a weakness, but it might
> make it easier for less-experienced developers to inadvertently expose a
> weakness.
>
> For example if it is possible to manipulate the client-side state, and we
> have to assume that if we can do it then it is possible (if difficult), so
> we have to ensure that every precaution is taken to ensure that we
> validate
> the state against allowable states for that user. In practice this is not
> trivial, we have to identify the appropriate validation to use for each
> application and set of data. The real danger of this is that we really
> would be seeing a move to a less secure model.
>
> Lets look at an example; If the state recorded is an account number for an
> account you are allowed to administer we can let you see your account
> details, but how can be be sure that you are still the person who is
> entitled to see that data? Obvious we make you log in (and http_auth
> ensures that the browser sends your password with every logged-in request)
> and compare the user we retrieve from the server with the one associated
> with the client-side state, in our example we also have to verify that the
> account is associated with a user you are allowed to administer. We will
> pretty quickly end up wishing that we had a server-side state we could use
> to validate requests against. Doesn't this defeat the purpose? I though
> that the whole principle behind sessions and session-id's was about moving
> state from the client into the server where it is secure and can't be
> tampered with.
> Is it not possible to split the state intellignently between client and
> server?
>
> As far as bandwidth is concerned I'm quite sure that my employer would be
> somewhat less than pleased if my new application consumed more bandwidth
> than an equivalent older one, someone has to pay for bandwidth and its
> often both parties, naievely put for a 100% marginal rise in traffic
> between two parties you get a 200% rise in marginal cost.
>
> d.
>
>
>
> ***************************************************************************
> The information in this e-mail is confidential and for use by the
> addressee(s) only. If you are not the intended recipient (or responsible for
> delivery of the message to the intended recipient) please notify us
> immediately on 0141 306 2050 and delete the message from your computer. You
> may not copy or forward it or use or disclose its contents to any other
> person. As Internet communications are capable of data corruption Student
> Loans Company Limited does not accept any responsibility for changes made
> to this message after it was sent. For this reason it may be inappropriate
> to rely on advice or opinions contained in an e-mail without obtaining
> written confirmation of it. Neither Student Loans Company Limited or the
> sender accepts any liability or responsibility for viruses as it is your
> responsibility to scan attachments (if any). Opinions and views expressed in
> this e-mail are those of the sender and may not reflect the opinions and
> views of The Student Loans Company Limit
> ed.
>
> This footnote also confirms that this email message has been swept for the
> presence of computer viruses.
>
> **************************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
Re: Forms in 4.1
Posted by Cliff Zhao <zh...@gmail.com>.
Although I'm not deep in Tapestry nor MS .Net, Tapestry seems to follow the
.Net track.
On 11/27/05, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> I think that was my original plan. One global configuration variable
> either
> enabling/disabling it, with the default being disabled. :)
>
> On 11/27/05, Kevin Menard <km...@servprise.com> wrote:
>
> > Now, if there's a way to transparently switch between non-AJAX and AJAX,
> > then that'll be cool.
> >
> > --
> > Kevin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
Re: Forms in 4.1
Posted by Jesse Kuhnert <jk...@gmail.com>.
I think that was my original plan. One global configuration variable either
enabling/disabling it, with the default being disabled. :)
On 11/27/05, Kevin Menard <km...@servprise.com> wrote:
> Now, if there's a way to transparently switch between non-AJAX and AJAX,
> then that'll be cool.
>
> --
> Kevin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
Re: Forms in 4.1
Posted by Kevin Menard <km...@servprise.com>.
On Sun, 27 Nov 2005 18:30:06 -0500, Jesse Kuhnert <jk...@gmail.com>
wrote:
> Hopefully the back button support can be fixed some when we get a chance
> to
> do more integration. We should be able to hook in the forward/back button
> support that dojo has into forms even when they're not ajax-based.
> (Hopefully the word ajax will lose meaning in 4.1 and it'll just be
> something that happens magically..)
I hope you're not implying that all of the base components will be
AJAX-enabled by default. There are quite a few of us that haven't been
totally sold on the idea yet and would rather not be paying the price for
stuff we're not using.
Now, if there's a way to transparently switch between non-AJAX and AJAX,
then that'll be cool.
--
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Jesse Kuhnert <jk...@gmail.com>.
Hopefully the back button support can be fixed some when we get a chance to
do more integration. We should be able to hook in the forward/back button
support that dojo has into forms even when they're not ajax-based.
(Hopefully the word ajax will lose meaning in 4.1 and it'll just be
something that happens magically..)
On 11/27/05, Norbert Sándor <de...@erinors.com> wrote:
>
> > I've to admit, as a global note, I'm not very comfortable with storing
> > states (and consequently what relates to states) on the client but i
>
> I think it is much better to store one big hidden field than many small...
> It is more efficient to encrypt and compress one big data than many
> smalls.
>
> Storing state on the client side is the best against BACK button and
> friends. :) (I hate these monsters :)
> I would be happy to see a solution which stores the state of the entire
> page
> on the client side.
> I know it is possible to enclose the entire page in a Form but it is
> neither
> efficient nor flexible.
>
> BR,
> Norbi
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
Re: Forms in 4.1
Posted by Norbert Sándor <de...@erinors.com>.
> I've to admit, as a global note, I'm not very comfortable with storing
> states (and consequently what relates to states) on the client but i
I think it is much better to store one big hidden field than many small...
It is more efficient to encrypt and compress one big data than many smalls.
Storing state on the client side is the best against BACK button and
friends. :) (I hate these monsters :)
I would be happy to see a solution which stores the state of the entire page
on the client side.
I know it is possible to enclose the entire page in a Form but it is neither
efficient nor flexible.
BR,
Norbi
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Danny Angus <Da...@slc.co.uk>.
Massimo Lusetti wrote:
>I've to admit, as a global note, I'm not very comfortable with storing
> states (and consequently what relates to states) on the client
I agree with Massimo, not only does bandwidth become an issue, but security
becomes more of an issue as well.
I'm not saying that it would necessarily expose a weakness, but it might
make it easier for less-experienced developers to inadvertently expose a
weakness.
For example if it is possible to manipulate the client-side state, and we
have to assume that if we can do it then it is possible (if difficult), so
we have to ensure that every precaution is taken to ensure that we validate
the state against allowable states for that user. In practice this is not
trivial, we have to identify the appropriate validation to use for each
application and set of data. The real danger of this is that we really
would be seeing a move to a less secure model.
Lets look at an example; If the state recorded is an account number for an
account you are allowed to administer we can let you see your account
details, but how can be be sure that you are still the person who is
entitled to see that data? Obvious we make you log in (and http_auth
ensures that the browser sends your password with every logged-in request)
and compare the user we retrieve from the server with the one associated
with the client-side state, in our example we also have to verify that the
account is associated with a user you are allowed to administer. We will
pretty quickly end up wishing that we had a server-side state we could use
to validate requests against. Doesn't this defeat the purpose? I though
that the whole principle behind sessions and session-id's was about moving
state from the client into the server where it is secure and can't be
tampered with.
Is it not possible to split the state intellignently between client and
server?
As far as bandwidth is concerned I'm quite sure that my employer would be
somewhat less than pleased if my new application consumed more bandwidth
than an equivalent older one, someone has to pay for bandwidth and its
often both parties, naievely put for a 100% marginal rise in traffic
between two parties you get a 200% rise in marginal cost.
d.
***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limit
ed.
This footnote also confirms that this email message has been swept for the presence of computer viruses.
**************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Danny Angus <Da...@slc.co.uk>.
> I don't know. It seems like everyone is treating this client state
problem
> as if it's a new security risk that isn't already there, unless I'm
missing
> something. People are currently allowed to specify whether they want
client
> or session based state management for any given property right?
Yeah, but Tapestry should, and does, abstract those concerns away from the
normal development.
The decision is taken once at the framework level. It is this decision
we're questioning.
> Does anyone know how any other framework handles these security concerns?
> Are we inventing problems that no one else is even addressing or ?....
Nope, we're re-introducing problems that everyone else has already
addressed.
It is good practice to use a client side key (session-id) for accessing
server-side state, the key can be combined with user identity management to
ensure that sessions cannot be stolen by manipulation of the key alone
(you'd also have to misapproriate the correct user's credentials).
I will accept that there may be a class of state which is trivial and might
be safely managed by round-trip to the client, but I'm not convinced that
it is beneficial.
>I'm not as knowledgable in this area, so it would be interesting to know
if
> anyone out there knows what the right way to do this is..
see above. ;-)
d.
***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limit
ed.
This footnote also confirms that this email message has been swept for the presence of computer viruses.
**************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Jesse Kuhnert <jk...@gmail.com>.
I don't know. It seems like everyone is treating this client state problem
as if it's a new security risk that isn't already there, unless I'm missing
something. People are currently allowed to specify whether they want client
or session based state management for any given property right?
Does anyone know how any other framework handles these security concerns?
Are we inventing problems that no one else is even addressing or ?....
I'm not as knowledgable in this area, so it would be interesting to know if
anyone out there knows what the right way to do this is..
jesse
On 11/28/05, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
>
> Jesse Kuhnert wrote:
> > 1) Provide a system/hivemind/whatever configurable property that
> specifies
> > the sort of encrytion scheme you'd like to use on these states...Could
> be
> > none/base64/blowfish/md5/sha/etc....Then only people who need it have to
> > take the performance hit.
> >
> hmmm I don't think basic security is an optional parameter. Remember
> that 80% of developers don't really take the time to learn a framework.
> A lot will just copy & paste some code and be on their way. That's kinda
> scary when you think about it.
>
> --
> Ing. Leonardo Quijano Vincenzi
> DTQ Software
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
Re: Forms in 4.1
Posted by Leonardo Quijano Vincenzi <le...@dtqsoftware.com>.
Jesse Kuhnert wrote:
> 1) Provide a system/hivemind/whatever configurable property that specifies
> the sort of encrytion scheme you'd like to use on these states...Could be
> none/base64/blowfish/md5/sha/etc....Then only people who need it have to
> take the performance hit.
>
hmmm I don't think basic security is an optional parameter. Remember
that 80% of developers don't really take the time to learn a framework.
A lot will just copy & paste some code and be on their way. That's kinda
scary when you think about it.
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Kent Tong <ke...@cpttm.org.mo>.
Norbert Sándor <developer <at> erinors.com> writes:
> I think that it can be solved by using some "standard" solutions:
> - encrypting some user specific data (for example a random generated client
> ID stored in the session)
A user may legitimately get "user=root" in a client side state in
a particular page, but it doesn't mean that he can legitimately
copy and paste that into the client side state of another page.
> - encrypting a time stamp (or validity intervall)
This will break the back button, right?
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Norbert Sándor <de...@erinors.com>.
I think that it can be solved by using some "standard" solutions:
- encrypting some user specific data (for example a random generated client
ID stored in the session)
- encrypting a time stamp (or validity intervall)
- etc.
BR,
Norbi
>> 1) Provide a system/hivemind/whatever configurable property that
>> specifies
>> the sort of encrytion scheme you'd like to use on these states...Could be
>> none/base64/blowfish/md5/sha/etc....Then only people who need it have to
>> take the performance hit.
>
> I think this is not that simple: How to prevent replay attacks? If
> user=root is encrypted as "kedf82", nothing can prevent the user from
> copy and pasting it. Injecting some sort of state into the data may
> prevent reply attacks but will also defeat the whole purpsoe of
> client-side state (the back button).
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Kent Tong <ke...@cpttm.org.mo>.
Jesse Kuhnert <jkuhnert <at> gmail.com> writes:
> 1) Provide a system/hivemind/whatever configurable property that specifies
> the sort of encrytion scheme you'd like to use on these states...Could be
> none/base64/blowfish/md5/sha/etc....Then only people who need it have to
> take the performance hit.
I think this is not that simple: How to prevent replay attacks? If
user=root is encrypted as "kedf82", nothing can prevent the user from
copy and pasting it. Injecting some sort of state into the data may
prevent reply attacks but will also defeat the whole purpsoe of
client-side state (the back button).
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Jesse Kuhnert <jk...@gmail.com>.
I remember reading a lot of talk in the tapestry-users list about security
and client state as well.
In a completely off-the-cuff thought sort of way I can see a few options
here:
1) Provide a system/hivemind/whatever configurable property that specifies
the sort of encrytion scheme you'd like to use on these states...Could be
none/base64/blowfish/md5/sha/etc....Then only people who need it have to
take the performance hit.
2) Provide a general guideline on how some of these things should be done.
For instance, it should be acceptable to say that a users identity will
always be stored in the servers session. Then, it doesn't really matter what
client-side data people are able to intercept/parse because they won't be
able to do anything with it unless their previously identified user has the
correct permissions.
Of course #2 would then imply that you have built-in runtime checks for
permissions, not just exclusionary ones that do/don't display links and
such. I have one such runtime/hivemind binding/etc implementation that I
could make publicly available, if I could find someone who'd be willing to
maintain it ;)
>
> > When a form is triggered, it will no longer render itself; instead it
> > will use the serialized stream to perform callbacks that reflect the
> > order in which the fields rendered in the first place.
>
> Have you thought about security implication? Just a guess...
>
Re: Forms in 4.1
Posted by Massimo Lusetti <ml...@gmail.com>.
On 11/27/05, Howard M. Lewis Ship <hl...@comcast.net> wrote:
> Thought I'd take a moment out from packing my house to describe what I'd
> like to do in 4.1.
Thanks, that's always interesting to know where the project may be
directed and have a good journey to your new home
> Basically, I want to effectively eliminate the rewind cycle. No more
> false rendering.
One thing i would have had even in 4.0
> When a form is triggered, it will no longer render itself; instead it
> will use the serialized stream to perform callbacks that reflect the
> order in which the fields rendered in the first place.
Have you thought about security implication? Just a guess...
> Things will still work for a volatile For within a Form ... though there
> are less guarantees than that the proper objects will be updated. I
> suspect that volatile For's will still register callbacks with the Form
> for each iteration, but the callback will be a bit different.
> Alternately, volatile For components will have no interaction with the
> enclosing Form. Still puzzling that out.
>
> If components will no longer need any interaction with the enclosing Form.
> In addition, it will become much less possible to "predict" what the
> hidden form fields for a Form component will look like, from a unit
> testing angle. The current XML based integration tests will become
> impossible to maintain. For my day contract, I'm starting to look a
> jWebUnit ... I hope to find a way to merge jWebUnit tests with
> Tapestry's mock servlet container. That would be an optimum solution!
That's would mean a path to follow even for application development testing?
> I would guess there would be a small performance hit for trivial forms,
> but as a form grows in complexity, the advantages of this 4.1 scheme
> would grow. This is largely because there would be a single object
> stream -> MIME conversion (with all that overhead, including gzip
> compression) vs. many small ones (for each value iterated by a For, etc.).
Does the portlet side of Tapestry be affected by this choice?
Almost in every portlet I've done or seen there's a small form...
> It's funny how, as Tapestry advances, I'm finding it easier and better
> to store MORE state on the client than on the server! Although I have
> been doing some thinking about a WebObjects style state management
> (effectively, a tree of page states for each page), I'm seeing less
> urgency in the need for that given the existence of DataSqueezer and
> MB's IPrimaryKeyConverter.
I've to admit, as a global note, I'm not very comfortable with storing
states (and consequently what relates to states) on the client but i
don't know so much (yet) of Tapestry internals so i just guess if this
could lead to wasting more bandwidth then what is actually needed if
the form MIME stream grows in size and/or in numbers per page, or
maybe this could be over headed by the typical page
animations/graphics/media goodness.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Norbert Sándor <de...@erinors.com>.
Maybe using the method you described it will be easier to implement more
complex form scenarios.
I mean for example rerendering a part of a form using AJAX. As I see this
will be much easier because form state will be stored in one giant hidden
field instead of lots of distincts (so it could be modified by AJAX response
handlers in 1 simple step!).
BR,
Norbi
----- Original Message -----
From: "Howard M. Lewis Ship" <hl...@comcast.net>
To: <ta...@jakarta.apache.org>
Sent: Sunday, November 27, 2005 9:58 PM
Subject: Forms in 4.1
> Thought I'd take a moment out from packing my house to describe what I'd
> like to do in 4.1.
>
> Basically, I want to effectively eliminate the rewind cycle. No more
> false rendering.
>
> There's going to be a new kind of interaction between the enclosing Form
> and the form control components, including For.
>
> As components render, they will register a submit-time callback. The
> callback identifies the component (i.e., ComponentAddress) and allows an
> additional arbitrary object to be stored as well. Somehow, integrated
> into this, will be code in the Form to re-tell the fields what their
> element name is. In other words, new method on IFormComponent and IForm.
>
> When a form is triggered, it will no longer render itself; instead it
> will use the serialized stream to perform callbacks that reflect the
> order in which the fields rendered in the first place.
>
> For and Table will be extended to provide a series of response-time
> callbacks during the render, that will be used to restore page state
> just before form control components are invoked using callbacks. In
> fact, there will probably be a new interface to describe the
> relationship between components like For and Foreach and the Form, as
> neither will need to have a client-side element id (or generate any
> hidden form fields).
>
> This is actually a much simpler design than what's present in 3.0 and
> 4.0 in many ways; it reflects my growing confidence in what has evolved
> out of the DataSqueezer. Further, the reason I felt so strongly about
> removing the (ill concieved) Action service was because maintaining that
> would prevent this evolution in the Form component.
>
> Things will still work for a volatile For within a Form ... though there
> are less guarantees than that the proper objects will be updated. I
> suspect that volatile For's will still register callbacks with the Form
> for each iteration, but the callback will be a bit different.
> Alternately, volatile For components will have no interaction with the
> enclosing Form. Still puzzling that out.
>
> If components will no longer need any interaction with the enclosing Form.
>
> It does mean that there'll be a large, MIME encoded object stream for
> every form, as a hidden form field. But much of the other logic will go
> away. I believe that there will no longer be the possibility of a
> StaleLinkException. The situations that may cause StaleLinkExceptions
> today may cause NPEs under this scheme.
>
> You can imagine that this object stream would look something like:
>
> <span jwcid="for">
> <input jwcid="name"/> <input jwcid="age"/>
> </span>
>
> MyPage/for callback <DecodePrimaryKey <Integer 10001>>
> MyPage/name callback <UpdateFromParameter 'name'>
> MyPage/age callback <UpdateFormParameter 'age'>
> MyPage/for callback <DecodePrimaryKey <Integer 12020>>
> MyPage/name callback <UpdateFromParameter 'name_0'>
> MyPage/age callback <UpdateFormParameter 'age_0'>
> etc.
>
> In addition, it will become much less possible to "predict" what the
> hidden form fields for a Form component will look like, from a unit
> testing angle. The current XML based integration tests will become
> impossible to maintain. For my day contract, I'm starting to look a
> jWebUnit ... I hope to find a way to merge jWebUnit tests with
> Tapestry's mock servlet container. That would be an optimum solution!
>
> I would guess there would be a small performance hit for trivial forms,
> but as a form grows in complexity, the advantages of this 4.1 scheme
> would grow. This is largely because there would be a single object
> stream -> MIME conversion (with all that overhead, including gzip
> compression) vs. many small ones (for each value iterated by a For, etc.).
>
> It's funny how, as Tapestry advances, I'm finding it easier and better
> to store MORE state on the client than on the server! Although I have
> been doing some thinking about a WebObjects style state management
> (effectively, a tree of page states for each page), I'm seeing less
> urgency in the need for that given the existence of DataSqueezer and
> MB's IPrimaryKeyConverter.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
>
>
--------------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.8/183 - Release Date: 2005. 11.
25.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Forms in 4.1
Posted by Jesse Kuhnert <jk...@gmail.com>.
I think this sounds like a huge step in the right direction :) I had a
couple of thoughts that I wanted to chime in with.
The callback identities would be nice to have applied to links as well as
forms. This would enable similar interactions with For/Foreach/etc outside
the context of a form, which would be as important for my use-cases as those
instances where a form is involved. Maybe it is only in how the identifiers
are stored that is different in the form scenerio?
Continuing on the identifier logic, someone else using what I think is Web
Objects (could be something..I always confuse the two) was giving me a hard
time about friendly urls. What you do here could concievably make them even
friendlier?
Ie http://<yourhost>/app/UserAdmin/EditUserPage/1134
Would take you to the edit page for that particular user. Or
something...That doesn't really mean anything for components I guess :/
In regard to client-side state management, I saw your new work with the swf
files, which is what I'm assuming you were referring to in regard to WO. The
dojo guys just finished adding in a new storage api system based off a
similar concept. Though I'm sure it's too new to reliably use right away,
for my uses it would be incredibly helpful. Basically tacos is fairly
useless in certain situations if you try and use client-side state
management because it doesn't go back and refresh all of your href links
everywhere. The storage subsystem could hold this sort of global state in a
nice little area for us :) Here is a link to their swf-based storage impl
test http://archive.dojotoolkit.org/nightly/tests/storage/test_storage.html.
In regard to jWebUnit, I was using it to test some parts of my app a long
time ago but eventually ditched it in frustration with them not syncing up
with whatever xml libraries were in use at the time.. (Some bug having to do
with cloning xml nodes) It's probably fixed now...I also just yesterday
started playing with htmlunit in tacos. It's all checked into cvs, but it
starts up a jetty container within the code and then hits one of my
pages..For my purposes it's not really going to be useable because mozilla's
Rhino java-based javascript engine interpreter isn't quite up to date enough
to handle all of the insanity involved in the dojo packages. You may want to
check htmlunit out as well though..I've used both now (htmlunit very very
slightly), but I like what htmlunit has to offer more so far.
I do still have a testing solution available via a FF plugin that allows
spidering of pages and unit test assertions (similar to selenium, only not
fundamentally flawed the way it is..) , it's just not really as much an
automated solution as would be nice :( Perhaps theirs an easy way to run a
headless version of mozilla. heh.
BTW, I think the grid widget (component) is going to get a lot of attention
on wednesdays 2pm est dojo irc meeting (freenet #dojo) if anyone was
interested in the goings-on of that work.
jesse
On 11/27/05, Howard M. Lewis Ship <hl...@comcast.net> wrote:
>
> Thought I'd take a moment out from packing my house to describe what I'd
> like to do in 4.1.
>
> Basically, I want to effectively eliminate the rewind cycle. No more
> false rendering.
>
> There's going to be a new kind of interaction between the enclosing Form
> and the form control components, including For.
>
> As components render, they will register a submit-time callback. The
> callback identifies the component (i.e., ComponentAddress) and allows an
> additional arbitrary object to be stored as well. Somehow, integrated
> into this, will be code in the Form to re-tell the fields what their
> element name is. In other words, new method on IFormComponent and IForm.
>
> When a form is triggered, it will no longer render itself; instead it
> will use the serialized stream to perform callbacks that reflect the
> order in which the fields rendered in the first place.
>
> For and Table will be extended to provide a series of response-time
> callbacks during the render, that will be used to restore page state
> just before form control components are invoked using callbacks. In
> fact, there will probably be a new interface to describe the
> relationship between components like For and Foreach and the Form, as
> neither will need to have a client-side element id (or generate any
> hidden form fields).
>
> This is actually a much simpler design than what's present in 3.0 and
> 4.0 in many ways; it reflects my growing confidence in what has evolved
> out of the DataSqueezer. Further, the reason I felt so strongly about
> removing the (ill concieved) Action service was because maintaining that
> would prevent this evolution in the Form component.
>
> Things will still work for a volatile For within a Form ... though there
> are less guarantees than that the proper objects will be updated. I
> suspect that volatile For's will still register callbacks with the Form
> for each iteration, but the callback will be a bit different.
> Alternately, volatile For components will have no interaction with the
> enclosing Form. Still puzzling that out.
>
> If components will no longer need any interaction with the enclosing Form.
>
> It does mean that there'll be a large, MIME encoded object stream for
> every form, as a hidden form field. But much of the other logic will go
> away. I believe that there will no longer be the possibility of a
> StaleLinkException. The situations that may cause StaleLinkExceptions
> today may cause NPEs under this scheme.
>
> You can imagine that this object stream would look something like:
>
> <span jwcid="for">
> <input jwcid="name"/> <input jwcid="age"/>
> </span>
>
> MyPage/for callback <DecodePrimaryKey <Integer 10001>>
> MyPage/name callback <UpdateFromParameter 'name'>
> MyPage/age callback <UpdateFormParameter 'age'>
> MyPage/for callback <DecodePrimaryKey <Integer 12020>>
> MyPage/name callback <UpdateFromParameter 'name_0'>
> MyPage/age callback <UpdateFormParameter 'age_0'>
> etc.
>
> In addition, it will become much less possible to "predict" what the
> hidden form fields for a Form component will look like, from a unit
> testing angle. The current XML based integration tests will become
> impossible to maintain. For my day contract, I'm starting to look a
> jWebUnit ... I hope to find a way to merge jWebUnit tests with
> Tapestry's mock servlet container. That would be an optimum solution!
>
> I would guess there would be a small performance hit for trivial forms,
> but as a form grows in complexity, the advantages of this 4.1 scheme
> would grow. This is largely because there would be a single object
> stream -> MIME conversion (with all that overhead, including gzip
> compression) vs. many small ones (for each value iterated by a For, etc.).
>
> It's funny how, as Tapestry advances, I'm finding it easier and better
> to store MORE state on the client than on the server! Although I have
> been doing some thinking about a WebObjects style state management
> (effectively, a tree of page states for each page), I'm seeing less
> urgency in the need for that given the existence of DataSqueezer and
> MB's IPrimaryKeyConverter.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>