Re: FW: [dspace-tech] cocoon error, item view
After reconfiguring our statistics and restarting DSpace I'm seeing the same sort of error as Susan Borda in the cocoon log: 2018-11-02 00:01:15,820 WARN org.apache.cocoon.components.xslt.TraxErrorListener - Can not load requested doc: unknown protocol: cocoon at file:///dspace/webapps/ROOT/themes/Mirage/lib/xsl/core/page-structure.xsl:547:130 Most of the messages are just informational and seem to be due to the system catching up on statistics. To be safe I'll disable our cron scripts which run every night to update stats until whatever the system is doing is complete. The other errors we're seeing look like this: 2018-11-02 00:05:25,935 WARN cocoon.access - org.apache.cocoon.ConnectionResetException: Connection reset by peer Has anyone else seen these errors and, more importantly, fixed the problem? Thank you, Walter R. On Monday, February 15, 2016 at 10:11:02 PM UTC-9, Germán Biozzoli wrote: > > Hi people > > I'm about to resurrect this message from Susan. > > We're exactly at the same point, but in our case seems to occur some > obscure problem relative to the authorization of the items. The "blank" > items were public and now the collection is restricted to a group of users. > Using the advanced authorization tool, we defined READ rights for the > group/item/collection and DEFAULT BITSTREAM READ for > group/bistream/collection. After that, no posibility to view the items, > neither administrator or some e-person from the group. Adding ADMIN, WRITE > and other rights does not make any effect, the only way to continue viewing > metadata is deleting all policies over the items. > > The error message is the same and restating Tomcat neither produces any > effect. > > It happens in a dev instance using 6.0-SNAPSHOT. > > Any ideas where to look for the error? > > Regards > Germán > > > > > > > 2015-12-15 18:30 GMT-03:00 Borda, Susan >: > >> Hi All- >> We never received a response to this question and unfortunately it >> continues to happen, again this morning for instance and once again a >> restart of Tomcat resolved the issue. >> >> Has anyone else had this problem? >> >> We are now running DSpace 5.4. >> >> Any advice would be great. >> >> Thank you! >> susan >> >> ‹ >> Susan Borda >> Digital Technologies Development Librarian >> Montana State University Library >> 406-994-1873 >> >> >> >> >> >> >> >> On 11/5/15, 2:51 PM, "dspac...@googlegroups.com on behalf >> of Erik Guss" >> on behalf of >> eg...@auth.lib.montana.edu > >> wrote: >> >> >Dear Community: >> > >> >particulars: CentOS6.7, tomcat7, dspace5.3, mirage2 xmlui, <10,000 items >> > >> >Today our DSpace was displaying an intermittent error. All functionality >> >worked except the View item. In other words, you could browse around, >> >search, and see hitlists. But when clicking on a handle's item view, the >> >menus would appear, but no item content. This condition was fixed by >> >restarting tomcat. I've included log snippets from cocoon and dspace.log >> >below, first from the unsuccessful item view at 12:19 PM, then from the >> >successful item view after restarting tomcat at 12:49 PM. The problem >> >seems to have something to do with the cache. At the time of the >> >problem, there were no postgresql errors, or catalina.out errors, and >> >top showed normal resource usage. >> > >> >**cocoon.log** >> >** item information is blank on the screen during this time frame 12:19 >> ** >> >2015-11-05 12:19:22,468 INFO org.apache.cocoon.caching.impl.CacheImpl - >> >Cache HIT for >> >> >PK_G-aspect-cocoon://DRI/12/handle/1/9083?pipelinehash=-398319662474980475 >> >5 >> >2015-11-05 12:19:22,468 INFO org.apache.cocoon.caching.impl.CacheImpl - >> >Cache MISS for >> >> >PK_G-aspect-cocoon://DRI/11/handle/1/9083_T-Navigation-8967015258021785944 >> >_T-ItemViewer--1872229765608651772 >> >2015-11-05 12:19:22,468 INFO org.apache.cocoon.caching.impl.CacheImpl - >> >Cache MISS for >> >> >PK_G-aspect-cocoon://DRI/10/handle/1/9083_T-Navigation-8967015258021785944 >> >2015-11-05 12:19:22,468 INFO org.apache.cocoon.caching.impl.CacheImpl - >> >Cache MISS for >> >PK_G-aspect-cocoon://DRI/9/handle/1/9083_T-Navigation-8967015258021785944 >> >2015-11-05 12:19:22,468 INFO org.apache.cocoon.caching.impl.CacheImpl - >> >Cache MISS for >> >> >PK_G-aspect-cocoon://DRI/8/handle/1/9083_T-Include-file:///usr/local/dspac >> >e/config/MSU-sidebar-menu.xml >> >2015-11-05 12:19:22,468 INFO org.apache.cocoon.caching.impl.CacheImpl - >> >Cache MISS for >> >> >PK_G-aspect-cocoon://DRI/7/handle/1/9083_T-SystemwideAlerts-1_T-Navigation >> >--5367372201529954577 >> >2015-11-05 12:19:22,469 INFO org.apache.cocoon.caching.impl.CacheImpl - >> >Cache MISS for >> >PK_G-aspect-cocoon://DRI/6/handle/1/9083_T-Navigation-5799876941772906259 >> >2015-11-05 12:19:22,469 INFO org.apache.cocoon.caching.impl.CacheImpl - >> >Cache MISS for PK_G-aspect-cocoon://DRI/5/handle/1/9083 >> >2015-11-05 12:19:22,469 INFO
[dspace-tech] CAPTCHA/reCAPTCHA for the Feedback form?
Has anyone implemented some form of CAPTCHA for use on the Feedback form? We seem to be getting more and more spam this way. We've used Google's reCAPTCHA on a few other projects and if memory serves, it requires some validation after submission. So for use with DSpace I assume that would mean changes to some Java classes somewhere, correct? Has anyone already implemented this, or have any other suggestions on cutting down spam through the feedback mechanism? Thanks! - Darryl -- Darryl Friesen, B.Sc., Programmer/Analystdarryl.frie...@usask.ca Library Systems & Information Technology,http://library.usask.ca/ University of Saskatchewan Library -- "Go not to the Elves for counsel, for they will say both no and yes" -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
Re: [dspace-tech] View Statistics links not working
Hi Walter, Glad to hear you've made some headway. You do *not* need to make Apache aware of port 8080, as that's Tomcat. If you are using mod_proxy_ajp or similar, then Apache should just know to forward requests to port 8009 (or whatever port Tomcat's AJP connector is responding too). As you've gotten a bit further, it might be worth looking at the explanation for using mod_proxy_ajp here again: https://wiki.duraspace.org/display/DSDOC6x/Installing+DSpace#InstallingDSpace-UsingSSLonApacheHTTPDinfrontofTomcat(runningonports80and443 ) Good luck, Tim On Thu, Nov 1, 2018 at 7:35 PM wrote: > Sometimes you have lucky accidents. When the upgrade of httpd failed I > uninstalled httpd and mod_ssl and > reinstalled them both. Not only did httpd start with the new version but > it gave me an error I hadn't seen before: > > [root@dspace36a tmp]# service httpd restart > Stopping httpd:[ OK ] > Starting httpd: [Mon Oct 29 12:10:46 2018] [warn] _default_ VirtualHost > overlap on port 443, the first has precedence >[ OK ] > > Ah-ha! There was a conflict between my vhosts.conf file and one of the > Include files that configures SSL. > I stripped out the redundancies and overlaps and now the site is secured > for ports 80 and 443 as expected. > Port 8080 is not secured but it was suggested that one unsecured port > might be needed for OAI so I'll leave > it like that. > > In general should I have a virtual host configuration for port 8080 also > or does it just fall through unchanged? > > Thanks for you help! > > > > On Monday, October 29, 2018 at 11:04:30 AM UTC-8, wlruth...@alaska.edu > wrote: >> >> Frustrated and starting fresh Monday morning. I commented out ALL of the >> virtual host configurations in >> my vhosts.conf file for ports 80 and 443; nothing remains. So, anything >> that goes through httpd will thus >> fall through the file untouched. Sure enough, as I expected, port 8080 >> continued to work just fine. So the >> problem must be in the httpd setup someplace. >> >> When I saw nothing obvious in the configuration I went back to the >> DSpace5.5 manual and might've found >> the culprit. There is a warning that Apache 2.4.2 (or lower) breaks the >> connection to the backend (Tomcat). >> I'd seen that warning before but, since it just said "Apache" (and I >> wasn't using httpd at the time) I thought it >> meant Apache Tomcat, so all was fine. Today I checked our version of >> httpd; we are running Apache/2.2.15. >> Updating httpd via yum gave the same version of httpd, just one compiled >> in Feb 2018 rather than Jul 2017. >> If that didn't fix the problem I'll obtain the source code and compile a >> version of httpd newer than v2.4.2. >> >> Stay tuned... >> >> Nope, that broke it so now even port 8080 doesn't work. Sigh... Looking >> for source code for Apache httpd. >> >> >> >> >> On Friday, October 26, 2018 at 1:23:45 PM UTC-8, wlruth...@alaska.edu >> wrote: >>> >>> Yes, it does make sense. It also means I must have something >>> misconfigured because the only way I can >>> currently access the site is if I explicitly specify http and port 8080 >>> - http://dspace36a.library.uaf.edu:8080/ >>> >>> >>> On Friday, October 26, 2018 at 12:37:42 PM UTC-8, Tim Donohue wrote: >>> >>> Hi Walter, >>> >>> No worries, we've all been newbies at some point :) >>> >>> Port 8080 is Tomcat. It should not be defined in Apache configuration. >>> Think of it this way, when you use Apache in front of Tomcat... your Tomcat >>> ports do *not* need to be publicly accessible. They are just internal ports >>> (only accessible on localhost). >>> >>> So, in the setup I described above, my *only public ports* are port 80 >>> and 443. I don't have port 8080 or port 8009 available publicly, so you >>> cannot access my site via http://my.url:8080/ (for example). Port 8080 >>> and 8009 are only accessible on the server (so they are private ports). >>> So, if I login to the server and do a "wget http://localhost:8080; then >>> Tomcat responds. And Port 8009 is just used for proxying requests between >>> Apache and Tomcat on that server. >>> >>> So, with regards to SSL, in my setup the only port where SSL is >>> configured is port 443. As I have port 80 (HTTP) requests redirecting to >>> port 443 (HTTPS), *all* public requests (except sometimes OAI, as >>> mentioned) go through SSL. *After* SSL is validated, those requests *all* >>> get proxied to Tomcat (via port 8009). Port 8009 and 8080 don't need SSL >>> (again, cause they are not public ports and cannot be accessed unless you >>> first login directly on the server). >>> >>> Does that start to make a bit more sense? >>> >>> Tim >>> >>> On Fri, Oct 26, 2018 at 3:28 PM wrote: >>> >>> Good to know. That should simplify things. >>> >>> Now for the embarrassing newb questions. I'm still not clear how my >>> httpd secures port 8080 >>> (which everything is going through
Re: [dspace-tech] Open informations about restricted items
Hi Paul, Unfortunately, that's something we're aware of. It's made it into several tickets: https://jira.duraspace.org/browse/DS-304 (XMLUI METS generator ignores authorization) https://jira.duraspace.org/browse/DS-1922 (Metadata of withdrawn items is accessible -- if you know the URL) https://jira.duraspace.org/browse/DS-1258 (Restrict access to mets.xml) As you'll see in the discussions of those tickets, we've tried to come up with some decent solutions, but have yet to find a way to actually fix this. The details in the "mets.xml" are required by the theming engine of the XMLUI, but likely should be somehow restricted only to that theming engine (perhaps only accessible on localhost?). If you or anyone else on this list has ideas on how to resolve this once and for all, it'd be welcome. It simply hasn't received enough detailed thought/digging to figure out a way to solve. Unfortunately, I'm not sure any of the core developers (Committers) will get back to this anytime soon as most of their efforts are currently on the upcoming DSpace 7.x release. - Tim On Fri, Nov 2, 2018 at 3:04 AM Paul Münch wrote: > Hello, > > I like to share an issue which bother me a little bit. We use DSpace 6.3 > with XMLUI. It is possible to see metadata and bitstream information of > restricted items, if someone knows the handle ( e.g. crawl all handles > of the repository ) and uses this URL: > [dspace-url]/metadata/handle/.../mets.xml ( or ./ore.xml ). The > bitstreams are not downloadable but everybody could look into restricted > information. > > Are you aware of this or have you some workarounds? > > Kind regards, > > Paul Münch > > -- > Philipps-Universität Marburg | UB > Digitale Dienste | Deutschhausstraße 9 | D018 > Tel. +49 06421 28-24624 <+49%206421%202824624> > -- > > > -- > All messages to this mailing list should adhere to the DuraSpace Code of > Conduct: https://duraspace.org/about/policies/code-of-conduct/ > --- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dspace-tech+unsubscr...@googlegroups.com. > To post to this group, send email to dspace-tech@googlegroups.com. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. > -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
[dspace-tech] Flex Paper
Hi All, Any one integrated flexpaper document viewer?. If anyone integrated please help me out. Regards, Manjunath Sajjan -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
Re: [dspace-tech] WORM submissions?
Hi Tony, Am 02.11.18 um 10:45 schrieb Tony Brian Albers: > No, not about actual living beings, but Write Once Read Many. > > Is it possible to make a collection only accept deposits and not let > the owner delete what he/she has deposited? […] it is possible, if I understand you correct. We use a LDAP-based group wich can only submit to one collection and there is no read access by default. I think it was this way, but you have to fiddle around a bit... - create a collection after that, assign roles - you should have a COLLECTION_XXX_SUBMIT and COLLECTION_XXX_DEFAULT_READ group after - add some steps for the people to work with the workflow - use Access Control / Authorizations and add a new policy "ADD" for the group or users who should submit - set DEFAULT_ITEM_READ and DEFAULT_BITSTREAM_READ to the people doing the workflow - remove READ for Anonymous after submission and workflow you have to move the item to the target collection, check "Inherit policies" and move it. I hope this is the right way, I struggled a bit with it. -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
[dspace-tech] WORM submissions?
No, not about actual living beings, but Write Once Read Many. Is it possible to make a collection only accept deposits and not let the owner delete what he/she has deposited? TIA /tony -- Tony Albers Systems Architect Systems Director, National Cultural Heritage Cluster Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. Tel: +45 2566 2383 / +45 8946 2316 -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
[dspace-tech] Open informations about restricted items
Hello, I like to share an issue which bother me a little bit. We use DSpace 6.3 with XMLUI. It is possible to see metadata and bitstream information of restricted items, if someone knows the handle ( e.g. crawl all handles of the repository ) and uses this URL: [dspace-url]/metadata/handle/.../mets.xml ( or ./ore.xml ). The bitstreams are not downloadable but everybody could look into restricted information. Are you aware of this or have you some workarounds? Kind regards, Paul Münch -- Philipps-Universität Marburg | UB Digitale Dienste | Deutschhausstraße 9 | D018 Tel. +49 06421 28-24624 -- -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
