[dancer-users] Methods Of retrieving request parameters

[WK]

Hi!

2016-07-12 20:54 GMT+03:00 Warren Young <wyml at etr-usa.com>:

> I gave cat(1) as an example of doing it right.  For a more complex example, consider sqlite3.  It will accept SQL via stdin or as a parameter following the database file name.  Should it instead accept SQL via only one path?  Should its interpret the SQL differently based on the input path?  No and no.  (And for the record, I think sqlite3 should *also* accept SQL in from a named file.)

Should sqlite3 (or cat) accept all three paths same time? Which one
should first, which last? Should those inputs just concatenated
together or should they divert each other in some order?

As far I understand when using param/params approach Dancer may take
same params 3 ways, but one of them wins,

So POSTing path with query and form params

/item/id/123?id=223

[id=333]

we start with 3 different id-s, but at end we have one of them. Is it
good design for app? I don't think so.

One way to solve this as early as possible is to have those 3
different methods and make those access 3 separate arguments, so
developer can choose, where from to read certain value. It leaves
choice to the developer.

Other way is to prioritize 3 possible ways and let one win over others
(maybe depending of context, like POST prefers form value over path or
query params). This way makes decision instead of developer and needs
more detailed documentation, it seems not flexible at all. It is very
cozy, covienient, but where you see flexibility?

Actually, I am not sure why Dancer had both param and params? And how
they deal with different ways to present params with same key?

> Look, I’m happy Dancer now has these new functions which let a developer restrict which sources they are willing to accept data from.  If you feel that doing so will improve your program, by all means, use these new functions.  My argument is against this apparent move to deprecate the preexisting flexible alternatives.  Reading the newer docs, one gets a sense that using param() and params() is always wrong.
>
> I’m willing to be convinced of that, but it will take actual proof, not vague handwaving arguments.

As far every HTTP-param is easily changeable on client side I don't
know which security concern may involved in this situation. I'd like
to read about these too.

Still, one attack vector I have in mind, even it is unlikely. Let's
say we have app with authentication middleware. Middleware checks user
ID from path and reads session ID from cookie, then it makes sure from
backend, that user ID and session match, so it flags connection
correct and gives it forward to app. In app path-ID and query-ID have
conflict, but last one wins because precedence and now we run our
query in rights of ID we read from query params. Seems like taking
over to me. Avoidable, if we make distinction, from where param is
readed.

wbr,
-- 
Kõike hääd,

Gunnar