| Previous · Next | |
| User | Message |
|
arjan
|
Date: 2/26/2011 5:16 pm · Subject: setScratch · Rating: -1
Hi all,The scratch can be set via the url by calling: ?op=setScratch;scratchName=abc;scratchValue=def If one would like to set two scratchValues this is not possible right now. Not because these values are not received in good order by WebGUI. They are. Multiple values for parameters with the same name are grouped in an array: { "scratchName" : [ "ActiveSourceGroup", "ActiveIssueGroup" ], "scratchValue" : [ "26", "18" ], "op" : "setScratch" } It's the way www_setScratch in WebGUI/Operation/Scratch.pm calles $session->form->process that makes that only one scratchvariable is saved in the scratch: $session->scratch->set("www_".$session->form->process("scratchName"),$session->form->process("scratchValue")); If this could be changed very easily for example like so: my @scratchNames = $session->form->process("scratchName"); my @scratchValues = $session->form->process("scratchValue"); foreach my $scratchName ( 0..$#scratchNames ) { $session->scratch->set("www_".$scratchNames[$scratchName],$scratchValues[$scratchName]); } Of course a check to make sure that not an extreme number of scratchvariables could be set should be added as well. But apart from that: is there a reason not to make it possible to save more than one scratchVariable? Kind regards, Arjan. -- Recent: http://www.lomcongres.nl/ Congres- en nieuwsbriefportaal met relatiebeheer systeem voor het Landelijk Overleg Milieuhandhaving Setting Standards, a a Delft University of Technology and United Knowledge simulation exercise on strategy and cooperation in standardization, http://www.setting-standards.com United Knowledge, internet voor de publieke sector Keizersgracht 74 1015 CT Amsterdam T +31 (0)20 52 18 300 F +31 (0)20 52 18 301 bureau@unitedknowledge.nl http://www.unitedknowledge.nl M +31 (0)6 2427 1444 E arjan@unitedknowledge.nl Bezoek onze site op: http://www.unitedknowledge.nl Of bekijk een van onze projecten: http://www.handhavingsportaal.nl/ http://www.setting-standards.com/ http://www.lomcongres.nl/ http://www.clubvanmaarssen.org/ |
| Back to Top |
Rate [ | ]
|
|
preaction
|
Date: 2/26/2011 5:52 pm · Subject: Re: setScratch · Rating: -1
It's not well-defined what order the name/value pairs must be processed in a URL. Just because it works now, doesn't mean it will always. How about we instead extend ?op=setScratch to allow arbitrary name=value pairs into the scratch instead? ?op=setScratch;one=1;two=2 <- sets "www_one" to 1 and "www_two" to 2
|
| Back to Top |
Rate [ | ]
|
|
arjan
|
Date: 2/26/2011 6:16 pm · Subject: Re: setScratch · Rating: -1
Ah, good point. Thought there probably would be a good reason for
that. You suggestion would work for me. Wouldn't some prefix be required? Or do we know that none of the content handlers ever need parameters if an operation is called? If so, shall I write this and put it in 7.10? Kind regards, Arjan. On 02/27/2011 12:52 AM, doug@plainblack.com wrote: preaction wrote: -- Recent: http://www.lomcongres.nl/ Congres- en nieuwsbriefportaal met relatiebeheer systeem voor het Landelijk Overleg Milieuhandhaving Setting Standards, a a Delft University of Technology and United Knowledge simulation exercise on strategy and cooperation in standardization, http://www.setting-standards.com United Knowledge, internet voor de publieke sector Keizersgracht 74 1015 CT Amsterdam T +31 (0)20 52 18 300 F +31 (0)20 52 18 301 bureau@unitedknowledge.nl http://www.unitedknowledge.nl M +31 (0)6 2427 1444 E arjan@unitedknowledge.nl Bezoek onze site op: http://www.unitedknowledge.nl Of bekijk een van onze projecten: http://www.handhavingsportaal.nl/ http://www.setting-standards.com/ http://www.lomcongres.nl/ http://www.clubvanmaarssen.org/ |
| Back to Top |
Rate [ | ]
|
|
preaction
|
Date: 2/26/2011 6:53 pm · Subject: Re: setScratch · Rating: -1
I can't see why we would need a prefix, but if anyone else can find a reason we could do it. I also don't see the need to prefix the scratch var with "www_" anymore, but I think that's because we currently make no guarantees about the (in)security of session scratch. Otherwise, it's up to the developer/admin to make sure nothing intercepts the pairs being sent to setScratch, if they are using something that requires setScratch, or that the name doesn't cause some other problem ('shop' might, for example). As we move away from using query strings as function specifiers / request routing, this will become less of a concern.
|
| Back to Top |
Rate [ | ]
|
|
perlDreamer
|
Date: 2/27/2011 1:16 am · Subject: Re: setScratch · Rating: -1
On 02/26/2011 04:53 PM, doug@plainblack.com wrote:> preaction wrote: > > I can't see why we would need a prefix, but if anyone else can find a > reason we could do it. Prefixing guarantees that anything that we set internally can't be set maliciously by some external url. The first thing I'd think of is the CSRF Token. Colin |
| Back to Top |
Rate [ | ]
|
|
arjan
|
Date: 2/27/2011 7:11 am · Subject: Re: setScratch · Rating: -1
1) He, that's a good reason not to change the www_ prefix, which is
yet something else. Would there also be a reason to prefix the
external variables?2) Some kind of referer checking, eighter by CSRF or otherwise, would make it impossible that a logged-in user is tricked in setting a scratch variable by user b by letting him click a malicious url. If a CSRF token would become required required for setting the scratch from the url, it would be necessary to make the CSRF token available as a template variable. Right now the CSRF token is not available as a template variable such as <tmpl_var session.scratch.webguiCsrfToken> or so. *Would it be a risk in itself to make the CSRF token available as a template variable?* Because this would be necessary or adding CSRF would defeat the purpose of the public scratch system, where you set a variable by url and retrieve it by template variable. Thanx Colin, kind regards, Arjan. On 02/27/2011 08:16 AM, colink@perldreamer.com wrote: perlDreamer wrote: -- Recent: http://www.lomcongres.nl/ Congres- en nieuwsbriefportaal met relatiebeheer systeem voor het Landelijk Overleg Milieuhandhaving Setting Standards, a a Delft University of Technology and United Knowledge simulation exercise on strategy and cooperation in standardization, http://www.setting-standards.com United Knowledge, internet voor de publieke sector Keizersgracht 74 1015 CT Amsterdam T +31 (0)20 52 18 300 F +31 (0)20 52 18 301 bureau@unitedknowledge.nl http://www.unitedknowledge.nl M +31 (0)6 2427 1444 E arjan@unitedknowledge.nl Bezoek onze site op: http://www.unitedknowledge.nl Of bekijk een van onze projecten: http://www.handhavingsportaal.nl/ http://www.setting-standards.com/ http://www.lomcongres.nl/ http://www.clubvanmaarssen.org/ |
| Back to Top |
Rate [ | ]
|
|
arjan
|
Date: 2/28/2011 6:01 am · Subject: Re: setScratch · Rating: -1
Sorry, the CSRF is already available as a template variable.
Apparently I made a type when testing this. So: no problem. On 27-02-11 14:11, dev@webgui.org wrote: arjan wrote: -- NIEUW: http://www.mediacalculator.unitedknowledge.nl/ Hoe verslaan de media het politieke nieuws? Wie haalt het nieuws en hoe werkt dat uit? Bekijk het in de MediaCalculator: mediacalculator.unitedknowledge.nl Recent: http://www.lomcongres.nl/ Congres- en nieuwsbriefportaal met relatiebeheer systeem voor het Landelijk Overleg Milieuhandhaving Setting Standards, a Delft University of Technology and United Knowledge simulation exercise on strategy and cooperation in standardization, http://www.setting-standards.com United Knowledge, internet voor de publieke sector Keizersgracht 74 1015 CT Amsterdam T +31 (0)20 52 18 300 F +31 (0)20 52 18 301 bureau@unitedknowledge.nl http://www.unitedknowledge.nl M +31 (0)6 2427 1444 E arjan@unitedknowledge.nl Bezoek onze site op: http://www.unitedknowledge.nl Of bekijk een van onze projecten: http://www.handhavingsportaal.nl/ http://www.setting-standards.com/ http://www.lomcongres.nl/ http://www.clubvanmaarssen.org/ |
| Back to Top |
Rate [ | ]
|
|
preaction
|
Date: 2/28/2011 10:24 am · Subject: Re: setScratch · Rating: -1
Okay, now I see why setScratch does what it does: It returns "", which means the request continues to go through the motions. Perhaps better for you, Arjan, would be a complete scratch service using JSON or something. Are you setting this via javascript or via someone clicking a link? |
| Back to Top |
Rate [ | ]
|
|
arjan
|
Date: 3/1/2011 2:51 am · Subject: Re: setScratch · Rating: -1
Doug,I'm not sure what the insight is, that you just had. Is it that a request moves through all contentHandlers and through all operations, unless it claims to be the last? In this case it's not the last, however, when you suggested to store every parameter I asked you: Or do we know that none of the content handlers ever need parameters if an operation is called? Do we? And if other content handlers later in the order of contentHandlers and the subdivision of operations, maybe do need parameters - even though op=setScratch is called - then we could have the variables prefixed. With scr for example, like so: op=setScratch;scr_myVar=315;scr_yourVar=a%nice%day; This would store www_myVar=315 and www_yourVar="a nice day". (This is the *other* prefixing, Colin was talking about.) The first prefix (scr_) is usefull, because you want to be able to filter only the parameters from the request that are for sure intended to be stored. The second prefix is usefull, because more is stored in the scratch. To make sure only variables that have been stored via a url can be retrieved from a url, only www_prefixed variables are returned. A complete scratch service using JSON/Javascript is already available, is it not? You already can store a json string in a scratch variable. Nothing needs to be added for that. I'm not using javascript in this case (yet). I'm doing it the right way - the accessible way - with progressive enhancement. What I'm doing is setting several scratch variables via forms. Several macro's on the same page use these same scratch variables as input parameters. Eg. one of the macro's displays a graph. With the forms you set several properties of the graph, like the period of time used (day/week/month) the duration (a week, four weeks). The result is seen incrementally with every click. It would be nice to be able to set several variables at once. It's not difficult to write. I see several implementations. Apparently using a prefix is the best option, because Doug indicated that the order in which a webserver processes the parameters in the url is not well specified. This works right works now, but this may not work in later implementations of Apache and other webservers. Colin added the suggestion to require a CSRF token. No problem there. Other problems? Kind regards, Arjan. On 28-02-11 17:24, doug@plainblack.com wrote: preaction wrote: -- NIEUW: http://www.mediacalculator.unitedknowledge.nl/ Hoe verslaan de media het politieke nieuws? Wie haalt het nieuws en hoe werkt dat uit? Bekijk het in de MediaCalculator: mediacalculator.unitedknowledge.nl Recent: http://www.lomcongres.nl/ Congres- en nieuwsbriefportaal met relatiebeheer systeem voor het Landelijk Overleg Milieuhandhaving Setting Standards, a Delft University of Technology and United Knowledge simulation exercise on strategy and cooperation in standardization, http://www.setting-standards.com United Knowledge, internet voor de publieke sector Keizersgracht 74 1015 CT Amsterdam T +31 (0)20 52 18 300 F +31 (0)20 52 18 301 bureau@unitedknowledge.nl http://www.unitedknowledge.nl M +31 (0)6 2427 1444 E arjan@unitedknowledge.nl Bezoek onze site op: http://www.unitedknowledge.nl Of bekijk een van onze projecten: http://www.handhavingsportaal.nl/ http://www.setting-standards.com/ http://www.lomcongres.nl/ http://www.clubvanmaarssen.org/ |
| Back to Top |
Rate [ | ]
|
|
preaction
|
Date: 3/1/2011 11:53 am · Subject: Re: setScratch · Rating: -1
The issue I brought up is that ?op=setScratch allows the request to continue, instead of maybe redirecting to someplace else without the query parameters. This means if I do: /home?op=setScratch;func=edit;title=new%20asset I will set a "func" scratch, a "title" scratch, and then see the edit screen for the home asset, which is not the expected outcome. A prefix isn't going to completely fix this problem, just move it somewhere else: What if my asset grabs all URL parameters and does something with them? In this case, even the current setScratch has a problem. I think we'd be better off with a version of setScratch that did not allow the request to continue. A version that instead redirected the user back to where they should be, like all our POST forms should be doing. Because some people might be expecting our unexpected behavior, we'd have to have a new operation for this for now. You could call it "setAllScratch" or something. It'd be simpler: Just dumps the query params into scratch and redirects back to $session->url->page. You wouldn't need to remember a prefix when you want to use it. The user would get the same result as the old setScratch. Then once this new one is in place, we can remove the old, broken setScratch in a future version and make the new way the only way. I think Colin was just remarking that if you did not have the www_ part of the scratch variable name set by setScratch, you could override the csrfToken, which would break the security of it. |
| Back to Top |
Rate [ | ]
|
