cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Escaping Sitemap Hell - side note
Date Thu, 06 Jan 2005 14:46:54 GMT
H.vanderLinden@MI.unimaas.nl wrote:

>Daniel,
>
>First off: great post. I agree with your ideas and reading through this post
>I realised I have tried implementing my URL space along these lines, ending
>up with a huge and very unclear sitemap, so every improvement is welcome.
>
Nice, I had the same realization when I read Tim BL.

>However, the example below is a bad one from a privacy/security POV:
>
Agree, I should have known better as we have worked quite a lot with 
interview data for medical research at my company a few years ago.

>>The idea is that an URL identifies a resource. For the patient case 
>>above it could be:
>>http://myhospital.com/person/123456789
>>    
>>
>
>In medical software your should always be aware that you will never expose
>identifying information to unauthorized persons. Therefore the above URL
>would be usable only in an environment where no unauthorized access to the
>software or even view of the screen is possible.
>
Yes agree. My view is that access rights in most cases should be based 
access right of the repository  (or other) content that your resource is 
constructed from, rather on being based on URL patterns. I wrote an RT 
about that a number of years ago: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101282731120086&w=2 
with current architecture the ideas in that RT is not that easy to 
realize, but with my current proposal it would be easier.

>Yes, I know that the first thing most medical software does is put some
>identifying data of the patient on the screen (such as name, address, gender
>and DOB) and often the ID in the current system as well. This is partly
>necessary (except for the ID part), but it should never ever be part of a
>cool URL that can be bookmarked or otherwise be addressed directly or stored
>outside the application.
>
Besides the risk that unauthorized people read your bookmark list, using 
the id is a bad idea , as people can use such URLs to query the system. 
If you as a system designer wasn't paranoid enough people can learn 
sensitive stuff from the difference between access denided and resource 
not found messages.

/Daniel

>In short, the ideas of cool URLs is great, but the implementation domain
>might require otherwise.
>
>Bye, Helma
>
>  
>



Mime
View raw message