I'm not sure I followed all of that... are you worried about having a
form nested within another form?
Yes, the forms will have to be outside the main form, but the links to
those forms can be inside the main form.
-David
On Apr 20, 2009, at 2:25 AM, Ashish Vijaywargiya wrote:
Hello David,
Below is your comments from rev no. 757316.
Changed back to throw an exception when a non-body parameter is
passed to
a secure request that calls a service as an event; now that >>we
have the
Form Widget and form defs fixed up to handle these better it should
be fine
for most things, but chances are there are some >>links in FTL files
that
will still be broken and will need to be manually fixed; with this
we can
look forward to more issues and >>questions/comments on the mailing
list,
but this also makes it a lot more secure and pretty difficult to
spoof one
of these requests (will >>have to hack HTTPS and encrypt the body to
do so)
Here you are saying that we may need to explicitly set the form
values in
the FTL files. But how should we handle the case when we have
"Delete" &
"Update" case on the list form that is build up using FTL file.
For Ex :
https://localhost:8443/catalog/control/EditCategoryParties?productCategoryId=CATALOG1
I have created form something similar to the above link but I am
confused
how should I handle this case in which we have "Update" & "Delete"
button.
It can be a stupid question but I tried my best to solve the problem
although didn't get success.
Thanks in advance for any help !
--
Ashish Vijaywargiya
On Sun, Apr 19, 2009 at 4:27 AM, David E Jones
<david.jo...@hotwaxmedia.com>wrote:
On Apr 18, 2009, at 4:48 AM, Jacques Le Roux wrote:
At
https://demo904.ofbiz.org/catalog/control/setUserPreference?userPrefGroupTypeId=GLOBAL_PREFERENCES&userPrefTypeId=COMPACT_HEADER&userPrefValue=Y
I get see this message.
Found URL parameter [userPrefTypeId] passed to secure (https)
request-map
with uri [setUserPreference] with an event that calls service
[setUserPreference]; this is not allowed for security reasons! The
data
should be encrypted by making it part of the request body (a form
field)
instead of the request URL.
That particular is already fixed, and just hasn't updated yet.
I thought we gave up with this message (or just have it only in
log?).
If a change had been made you would have seen it in the commit
log... and
hopefully explicitly called out as such (it is unfortunate that we
get so
many poorly written commit logs that don't even try to describe the
changes
made...).
But I was just thinking about that yesterday and I think that we
should
contunue to have it in trunk and not in 9.04. So we will be able
to catch
them (before having a tool to list them all, I hope to work on
that next
week) without disturbing 9.04 users
The main point of that error is to protect against XSRF attacks.
Without
that error and not allowing the condition it checks there is
nothing keeping
spoofed parameters from piggy-backing on a cloned encrypted request
(or
caught and modified through a man-in-the-middle sort of attack).
Personally I'd rather see these fixed in both the release branch
and in the
trunk, but if we get too many complaints about it in the release
branch then
I'm totally fine disabling that constraint temporarily.
-David
