Daring to go even further, I think it's quite paranoid to obfuscate
database ids.
The danger of database ids in urls is not that people know about it
but they can fake them by altering the url. So the solution is not
some snakeoil-like encryption of the id but proper and thorough
checking of the id coming from the url before further processing
Just my 2%
Am 13.12.2008 um 11:31 schrieb Ayodeji Aladejebi:
Michael Sparer blogged at
http://talk-on-tech.blogspot.com/2008/12/wicket-neat-url-encoding-strategy-and.html
and discussed certain approach for encoding and decoding IDs in
parameters.
The general use of encoding strategies I understand but
I really wanted to understand why the complexity of using
CodingStrategies
especially for encoding database IDs. Why is this simply a problem:
PageParameter param = new Long dataId = new Long(23);
param.put("dataId", encodeAsString(23)); setResponsePage(...); then
when you
are parsing the Parameters, you simple say Long dataId =
decodeToLong(param.get("dataId")); the bookmarkable page param will
still
show as in browser as ?dataId=ajdladjasdsdkklsadkals& as yu want it
and your
encodeAsString and decodeToLong could be in a static class or a
super Panel
or Page?
Please dont mind me, I am not a fan of complexity
--
Aladejebi Ayodeji A.,
DabarObjects Solutions
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
