Hi Mike I have created http://fedora-commons.org/jira/browse/FCREPO-727 for this - this is technically a regression as it was possible to do this in releases prior to 3.2.
Opinions welcomed on whether the datastream ID should link to the profile (as it does at the moment) with an additional "content" link; or whether the ID should link to the content (as it used to prior to 3.2) with an additional "profile" link. I have also added an FAQ on customising these HTML views (http://fedora-commons.org/confluence/x/Y4Y9AQ). They're produced by XSLT stylesheets which are in the server/access and server/management directories - so it is listDatastreams.xslt in access for this particular view. As a work-around ff you wanted to revert to the previous behaviour you'd need to look around line 77, and add the line <xsl:text>/content</xsl:text> just before it - depending on your XSLT skills you could of course implement links to both profile and content as per the JIRA ticket. Regards Steve > -----Original Message----- > From: Mike Korcynski [mailto:[email protected]] > Sent: 18 June 2010 15:28 > To: 'Fedora Users' > Subject: Re: [Fedora-commons-users] Change in Datastreams > behavior afterupgradeto 3.3 > > > Hi Steve, > > Thanks for the follow up, I believe theArchivists here have > student workers use the FedoraUI to obtain datastream > content. This will be an odd regression from our previous > 3.1 installation, having to now give students a password for > API-M access when they shouldn't have that level of access. I > would think if you provide anonymous API-A access then the > datastream content should be navigable and not something you > have to compute on the address bar of the browser. It may > make sense to have a configuration to override the link > from the datastreams list to point to the content directly > and bypass the new profile screen altogether. > > Thanks, > > -Mike > > > On 6/17/10 2:21 PM, Steve Bayliss wrote: > > Hi Mike > > > > Actually my previous email is wrong - ignore it. > > > > The datastream profile view is API-M - so does require > authentication (it's > > actually one of the underlying calls we were previously > using for generating > > the content-disposition header and therefore the reason you > were getting > > prompted for auth for datastream content). > > > > Regards > > Steve > > > > > >> -----Original Message----- > >> From: Steve Bayliss [mailto:[email protected]] > >> Sent: 17 June 2010 17:32 > >> To: 'Mike Korcynski' > >> Cc: 'Fedora Users' > >> Subject: Re: [Fedora-commons-users] Change in Datastreams > >> behavior afterupgradeto 3.3 > >> > >> > >> Hi Mike > >> > >> Yes, we've moved the underlying calls to API-A for the > next release to > >> resolve this (though if there are XACML restrictions on the > >> underlying calls > >> that will still cause issues - listDatastreams and > >> getDatastreamDissemination for RELS-INT). > >> > >> The "datastream profile view" shouldn't in fact trigger auth, > >> as far as I am > >> aware (it is API-A). > >> > >> So I can reproduce this, could you supply: > >> (1) the datastream profile view URL that's triggering the > auth request > >> (2) your fedora/install/install.properties (with any sensitive bits > >> obfuscated) > >> (3) any changes you've made to fedora.fcfg > >> (4) any XACML policies over and above the default policies > >> that you've added > >> > >> Thanks > >> Steve > >> > >> > >>> -----Original Message----- > >>> From: Mike Korcynski [mailto:[email protected]] > >>> Sent: 17 June 2010 17:22 > >>> To: Steve Bayliss > >>> Cc: 'Fedora Users' > >>> Subject: Re: [Fedora-commons-users] Change in Datastreams > >>> behavior after upgradeto 3.3 > >>> > >>> > >>> Steve, > >>> > >>> Thanks for the reply, that does solve part of the problem. This > >>> improves the situation in that now the content can be > >>> accessed by direct > >>> URL without authentication being triggered however the > >>> intermediate page > >>> "Datastream Profile View" triggers the auth request so a user > >>> would only > >>> be able to get to the content if they could figure out the > >>> direct URL to > >>> the content. From your description of the problem, and reading > >>> FCREPO-703 it appears you guys have addressed this by shifting the > >>> implementation to use API-A calls for Profile View so > this is fully > >>> resolved in the next release? Thanks for the description > >>> that helped a > >>> lot in making sense of the issue. > >>> > >>> -Mike > >>> > >>> On 6/17/10 11:43 AM, Steve Bayliss wrote: > >>> > >>>> Hi Mike > >>>> > >>>> This sounds like the bug that crept in as part of > >>>> > >>> FCREPO-497 - now fixed in > >>> > >>>> trunk by FCREPO-703. > >>>> > >>>> To verify this, could you locate in your fedora.fcfg theparameter > >>>> "datastreamFilenameSource", and change the value from "rels > >>>> > >>> label id" to "id > >>> > >>>> label rels". > >>>> > >>>> Optionally you could change the parameter > >>>> "datastreamContentDispositionInlineEnabled" to "false" also. > >>>> > >>>> These two parameter control the new content-disposition > >>>> > >>> header that is sent > >>> > >>>> so that users get a sensible filename when downloading - > >>>> > >>> setting the latter > >>> > >>>> parameter to false disables the header altogether, changing > >>>> > >>> the former to > >>> > >>>> "id label rels" means that the datastream ID will be used > >>>> > >>> (otherwise in 3.3 > >>> > >>>> API-M calls are made to determine relationships and > >>>> > >>> datastream label, hence > >>> > >>>> the authentication request). > >>>> > >>>> Steve > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Mike Korcynski [mailto:[email protected]] > >>>>> Sent: 17 June 2010 16:20 > >>>>> To: Fedora Users > >>>>> Subject: [Fedora-commons-users] Change in Datastreams > >>>>> behavior after upgradeto 3.3 > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> We recently upgraded from Fedora 3.1 to 3.3 and have noticed > >>>>> a change in > >>>>> the behavior when accessing the Datastream Profile View and > >>>>> Datastream > >>>>> content. In our current configuration we enforce XACML, > >>>>> disable FeSL, > >>>>> and allow anonymous API-A access. Much like in 3.1 I can > >>>>> > >>> anonymously > >>> > >>>>> access the Datastream list "/datastreams" but when I click > >>>>> > >>> through to > >>> > >>>>> the new profile screen I'm prompted for username/password. > >>>>> Is this an > >>>>> intentional change requiring authentication for this step and > >>>>> for access > >>>>> to actual content? It seems a bit odd, as you can still > >>>>> > >> access the > >> > >>>>> content anonymously through methods. I couldn't find > >>>>> reference to this > >>>>> change in the release notes for 3.2 or 3.3 so I was hoping > >>>>> someone here > >>>>> might provide some insight. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Mike > >>>>> > >>>>> > >>>>> -- > >>>>> Mike Korcynski > >>>>> Software Engineer > >>>>> University Information Technology - Academic Technology > >>>>> Tufts University > >>>>> 16 Dearborn Road, Medford, MA 02144 > >>>>> Phone: 617.627.4957 > >>>>> http://uit.tufts.edu/at/ > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -------------------------------------------------------------- > >>>>> ---------------- > >>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate > >>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > >>>>> lucky parental unit. See the prize list and enter to win: > >>>>> http://p.sf.net/sfu/thinkgeek-promo > >>>>> _______________________________________________ > >>>>> Fedora-commons-users mailing list > >>>>> [email protected] > >>>>> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> -------------------------------------------------------------- > >> ---------------- > >> ThinkGeek and WIRED's GeekDad team up for the Ultimate > >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > >> lucky parental unit. See the prize list and enter to win: > >> http://p.sf.net/sfu/thinkgeek-promo > >> _______________________________________________ > >> Fedora-commons-users mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > >> > >> > > > > > -------------------------------------------------------------- > ---------------- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Fedora-commons-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
