On Wed, Jun 6, 2012 at 11:19 AM, Tim Donohue <[email protected]> wrote:
>
>
> On 6/6/2012 12:36 PM, Mark Diggory wrote:
>
>> Personally, I never thought it good to expose the DRI or METS used in
>> rendering the ui publically outside the ui. It...
>> A) forces us to worry about questions like securing access to the
>> content used in rendering decisions that should not be shared with the
>> world.
>>
>> B) conflates the content generation phase of the UI as a Public API...
>> Which it really shouldn't be. We do not guarantee any of these exposed
>> renderings as an API.
>> Generally, it's rather insecure to expose the write permissions on
>> resources, your going to be telling any attackers the names of accounts
>> or groups of accounts to try to hack depending on those policies. Since
>> they have access to the code, they can work to find a vulnerability.
>> There's being open, then there's being foolhardy.
>>
>
> Admittedly though, it goes both ways.
>
> Not exposing this information in DRI/METS via the UI makes it more complex
> to develop complex Themes in XSLT. So, it is an extremely powerful tool for
> developers as they work to build new cool themes.
>
I agree, we need to be able to render the detail, at this time we are using
our own transformers to get the rights rendered in the administrative UI. A
general strategy for use in the Item or other views will be necessary to
present that the Item or Bitstream is embargoed to the enduser.
> However, I do agree that once you go into "Production" mode, there should
> be some way to turn this off publicly if you want to (e.g. limit DRI/METS
> access to localhost / certain trusted IPs).
It may not always be desirable for the general public to be able to play
> around with any of your enabled DSpace Crosswalks to see what they can find.
>
> - Tim
>
This is different from what we are discussing above, for XSLT rendering,
the application should always be able to interrogate the permissions to
control access to content being transformed to html. Its exposing
it publicly to the browser without rendering that is detrimental.
I recommend a dspace.cfg setting to enable a "debug" or "development" mode
and either a Cocoon selector or matcher that will properly secure the DRI
and /metadata/... pipelines from public view. We will also need to discuss
mediating any ability to expose this detail via OAI, SWORD, LNI. But I
think the XMLUI is the only place you can selectively call what crosswalks
should be rendered inside the METS output.
Mark
--
[image: @mire Inc.]
*Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
