Re: [OT] Not everything goes well in Ruby land :-)

There is more to not exposing primary keys than security.

If you expose any "developer private" information, users are going to =20=

start to rely on it. Consider it UI. Preventing you from making =20
changes. I.e. Users could start bookmarking URLs with primary keys in =20=

them.

I used to work on a project where the project manager gave the users =20
read-only access to the database. They started making requests for =20
changes to the data model, wanted views for the data model to behave =20
like its ancestor ... They wrote M$ Access "applications" digging into =20=

the schema. Any future change on our side will require maintenance to =20=

these proliferating "applications"

On two occasions, I ran into a gaping security hole in the "secure =20
message" system of the web banking I use. The interface was so broken =20=

that it seemed easier to modify the URL than to navigate as designed. =20=

Wanting to go to my next message I +1ed the message ID in the URL. =20
Guess what? I got to see another customer's messages. I spent 1 week =20
explaining the bank that this was a security issue. In the end they =20
agreed and fixed it. A year later I discovered they had it fixed for =20
INBOX, not for the SENT mailbox.

Best,
Pierre Bernard
Houdah Software s.=E0 r.l.

On 7 Jan 2008, at 23:24, Chuck Hill wrote:

>
> On Jan 7, 2008, at 2:10 PM, Pierce T. Wetter III wrote:
>
>>
>>> What do you think? What are the goods and the bads of exposing PKs =20=

>>> in URLs?
>>
>>  It depends on what they look like.
>>
>>  I always expose _encrypted_ primary keys in my URLs, so that =20
>> people can't generalize:
>>
>> 10000001
>> 10000002
>> 10000003
>>
>> etc.
>
>
> But why?  I am not a big fan of security though obscurity.  If there =20=

> are security issues, you need to check the permission to view (as =20
> you note below).  If there are no security issues (say items in a =20
> catalog), what does it matter?
>
>
>> There's a method in Wonder that makes this easy.
>>
>>  After that, since URLs are always in the browser history anyways, =20=

>> for things that have to be secure, I have a method that takes the =20
>> encrypted primary key, a key path, and session.user and makes sure =20=

>> that if you follow the specified key path from the object pointed =20
>> at by the encrypted primary key, that you reach session.user.
>
> Chuck
>
> --=20
>
> Practical WebObjects - for developers who want to increase their =20
> overall knowledge of WebObjects or who are trying to solve specific =20=

> problems.
> http://www.global-village.net/products/practical_webobjects
>
>
>
>
>
> _______________________________________________
> WebObjects-talk mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/webobjects-talk

---
Pierre Bernard
http://www.bernard-web.com/pierre
http://www.houdah.com