Re: [Dspace-tech] More enterprise deployment questions
Hi Andrew, Sorry for the delay in response here. Been busy these past few days. On 1/27/2014 10:53 AM, Andrew Reid wrote: Yes -- it happens both for my soon-to-deploy test system and my mostly-clean DSpace 3.2 prototype. It's mod_jk from an Apache front end to Tomcat in the back. There's a sym-link trick, the actual app is behind a symlink with a # in it, which Tomcat converts to a slash. Long way to say that, yes, the base URL is host/dspace/xmlui. The actual URL that our security folks' scanner picked up was host/dspace/xmlui/static/js/discovery/badfile123.js, which is apparently some kind of likely penetration vector. The actual error is, An error has occurred, which is apparently an HTTP 500 response. Without the static (for host/dspace/xmlui/js/discovery/badfile123.js), I get a different error, it's a Resource not found, again with the stack-traces. Since Friday, I have also subsequently heard that my security folks are unhappy with the 500 response -- can you (or anyone) offer them some assurances that this is benign? I noticed, while poking around, that other public-facing DSpace installations do the same thing -- I won't mention any names, since it's at least possible it's some kind of security issue. I am able to replicate the 500 response you are seeing. It *only* seems to occur for URLs of this structure: [dspace-xmlui-url]/static/*/*.js [dspace-xmlui-url]/static/*/*.css [dspace-xmlui-url]/static/*/*.json In other words, the XMLUI path must start with /static/, and it must end with either .js, .css or .json. So, it's a very specific URL structure that throws this 500 response (all others will return 404 responses). The underlying error *IS BENIGN*. Essentially, what is going on here is that we have some special processing to allow institutions to easily add custom Javascript or CSS files to their themes. Those custom files become available on the /static path. Currently, if someone attempts to reference a .js/.css/.json file which does NOT exist, DSpace code is unfortunately is throwing a Java NullPointerException (as it's failing to check if the file actually exists). Here's the line where the NullPointerException is thrown: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/cocoon/ConcatenationReader.java#L174 While this error is annoying and should be caught (and a proper 404 returned), it is a benign error. No javascript is being executed, and no problems are being caused in your DSpace instance..it's just a minor bug in the code. That all being said, I've opened up a bug ticket to report this benign issue. It seems like it shouldn't be too hard to fix, so hopefully we can get someone to resolve it in the near future. Please feel free to forward this bug ticket on to your security folks if it helps: https://jira.duraspace.org/browse/DS-1896 The prototype system is the one where I have tried putting the error-handling code in the webapps/xmlui/themes/Mirage/sitemap.xmap file -- I see the same behavior both with and without this code. After making changes to this file, I am restarting Tomcat, and I am frequently clearing my browser cache, so hopefully I am avoiding simple statefulness mistakes. I'm still not entirely sure what could be the difference here. I will admit however that I'm *not* using mod_jk/Apache in my testing. I'm going directly against Tomcat (version 7) on port 8080. You also should obviously make sure that the sitemap.xmap you are changing is the one in the xmlui/ directory that Tomcat is actually using. So, if Tomcat is loading the [dspace.dir]/webapps/xmlui/ directory, then you should edit the sitemap in that location (and not the one under your [dspace-source] directory). I've also done some further work in the ticket yesterday, which may be of interest. https://jira.duraspace.org/browse/DS-1596 I'm now attempting to get common errors (404, even 500) to display within your existing DSpace theme (e.g. Mirage or whatever), rather than displaying that ugly stacktrace page (which is the default). I've linked to a GitHub pull request off that ticket, which is the first attempt (only works for Mirage so far, but will be updated for all Themes). So, that may also be of interest. I'm still not sure what the difference is with the static error pages. I may need to look at this closer to figure out the difference, or just create an easily installable patch to ensure we are doing the same thing. - Tim -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
Re: [Dspace-tech] More enterprise deployment questions
On Thu, Jan 30, 2014 at 10:53:34AM -0600, Tim Donohue wrote: Hi Andrew, Sorry for the delay in response here. Been busy these past few days. Responses in-line below. On 1/27/2014 10:53 AM, Andrew Reid wrote: Yes -- it happens both for my soon-to-deploy test system and my mostly-clean DSpace 3.2 prototype. It's mod_jk from an Apache front end to Tomcat in the back. There's a sym-link trick, the actual app is behind a symlink with a # in it, which Tomcat converts to a slash. Long way to say that, yes, the base URL is host/dspace/xmlui. The actual URL that our security folks' scanner picked up was host/dspace/xmlui/static/js/discovery/badfile123.js, which is apparently some kind of likely penetration vector. The actual error is, An error has occurred, which is apparently an HTTP 500 response. Without the static (for host/dspace/xmlui/js/discovery/badfile123.js), I get a different error, it's a Resource not found, again with the stack-traces. Since Friday, I have also subsequently heard that my security folks are unhappy with the 500 response -- can you (or anyone) offer them some assurances that this is benign? I noticed, while poking around, that other public-facing DSpace installations do the same thing -- I won't mention any names, since it's at least possible it's some kind of security issue. I am able to replicate the 500 response you are seeing. It *only* seems to occur for URLs of this structure: [dspace-xmlui-url]/static/*/*.js [dspace-xmlui-url]/static/*/*.css [dspace-xmlui-url]/static/*/*.json In other words, the XMLUI path must start with /static/, and it must end with either .js, .css or .json. So, it's a very specific URL structure that throws this 500 response (all others will return 404 responses). Actually, I am also seeing it for paths that start with /theme/, for whatever that's worth -- possibly the same idea, special processing is happening? The underlying error *IS BENIGN*. Essentially, what is going on here is that we have some special processing to allow institutions to easily add custom Javascript or CSS files to their themes. Those custom files become available on the /static path. Currently, if someone attempts to reference a .js/.css/.json file which does NOT exist, DSpace code is unfortunately is throwing a Java NullPointerException (as it's failing to check if the file actually exists). Here's the line where the NullPointerException is thrown: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/cocoon/ConcatenationReader.java#L174 While this error is annoying and should be caught (and a proper 404 returned), it is a benign error. No javascript is being executed, and no problems are being caused in your DSpace instance..it's just a minor bug in the code. That all being said, I've opened up a bug ticket to report this benign issue. It seems like it shouldn't be too hard to fix, so hopefully we can get someone to resolve it in the near future. Please feel free to forward this bug ticket on to your security folks if it helps: https://jira.duraspace.org/browse/DS-1896 Thanks so much for running that down -- I'm glad it's benign. The folks who run the penetration testing set-up here also seemed to think it was a mis-categorized 404, but they weren't sure, and the NullPointer bugged them a lot. I'm also unclear on the differences (which were discussed in text I've deleted, for those following along at home) between your set-up and mine -- I may try a simpler set-up in my copious spare time, just to see if I can nail it down. What I have actually done, in the interests of getting my system deployed, is edited the xmlui/exception2html.xslt file to suppress the trace-backs -- since your fixes inside the themes can miss some errors thrown by xmlui, this seems like the right scope, although it does mean that I don't have access to the styling. From my perspective, that's a non-urgent issue that would be interesting to follow up on. These meassures are to get the system deployed, which is now happening. I'm still interested in following up on doing this better, and maybe getting the theme stuff right, but at a more leisurely pace. -- A. -- Dr. Andrew C. E. Reid Physical Scientist, Computer Operations Administrator Center for Theoretical and Computational Materials Science National Institute of Standards and Technology, Mail Stop 8555 Gaithersburg MD 20899 USA andrew.r...@nist.gov -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds.
Re: [Dspace-tech] More enterprise deployment questions
On Fri, Jan 24, 2014 at 03:47:22PM -0600, Tim Donohue wrote: Hi Andrew, On 1/24/2014 2:46 PM, Andrew Reid wrote: Huh. This is not working for me -- I have a testing installation with the default Mirage theme, and I am adding the lines from your comment directly in Mirage/sitemap.xmap, rather than rebuilding the app -- I mention this because it might be part of the issue. I may be using weird errors, too, my testing URL is host/dspace/xmlui/static/wrong.html, or host/dspace/xmlui/static/wrong.js -- they give different errors, the former gives a ResourceNotound with a big long Cocoon back-trace, and the second one gives a NullPointerException, with a very short Cocoon back-trace. Modifying Mirage/sitemap.xmap did not change this behavior -- I double-checked that the additional handle-errors map is *inside* the map:pipelines tag and *outside* any of the other map:item tag-pairs. Are my errors too weird? Am I actually getting *two* errors somehow? Vandalizing the top-level sitemap.xml is starting to look like the near-term solution, but I'd be willing to invest a bit more effort in a nicer answer. I'm probably going to need more info. It sounds like our two setups are different in some waythough admittedly, all of this work is extremely new (working on it *today*). So maybe I've overlooked something too. What does the URL to your DSpace homepage look like? Is it host/dspace/xmlui/? Yes -- it happens both for my soon-to-deploy test system and my mostly-clean DSpace 3.2 prototype. It's mod_jk from an Apache front end to Tomcat in the back. There's a sym-link trick, the actual app is behind a symlink with a # in it, which Tomcat converts to a slash. Long way to say that, yes, the base URL is host/dspace/xmlui. The actual URL that our security folks' scanner picked up was host/dspace/xmlui/static/js/discovery/badfile123.js, which is apparently some kind of likely penetration vector. The actual error is, An error has occurred, which is apparently an HTTP 500 response. Without the static (for host/dspace/xmlui/js/discovery/badfile123.js), I get a different error, it's a Resource not found, again with the stack-traces. Since Friday, I have also subsequently heard that my security folks are unhappy with the 500 response -- can you (or anyone) offer them some assurances that this is benign? I noticed, while poking around, that other public-facing DSpace installations do the same thing -- I won't mention any names, since it's at least possible it's some kind of security issue. The prototype system is the one where I have tried putting the error-handling code in the webapps/xmlui/themes/Mirage/sitemap.xmap file -- I see the same behavior both with and without this code. After making changes to this file, I am restarting Tomcat, and I am frequently clearing my browser cache, so hopefully I am avoiding simple statefulness mistakes. -- A. Also, what happens if you remove the /static/ subpath? (That actually *IS* a valid subpath in DSpace, and there's some special logic to deal with that subpath which could be causing issues here.) Covered above, it converts the 500 to a 404, but does not change the presentation of the errors. In any case, here's what works for me (on DSpace 4.0, but it should be the same for 3.2). In the example below [dspace.dir] represents the directory where DSpace is *installed*. 1. For me, Tomcat is loading the DSpace XMLUI from [dspace.dir]/webapps/xmlui/ (it's a completely fresh install of DSpace 4) 2. Create an error.html under [dspace.dir]/webapps/xmlui/themes/Mirage/ (making sure it's obviously readable to Tomcat) 3. Modify the sitemap.xmap under [dspace.dir]/webapps/xmlui/themes/Mirage/ For a simple test just add this: map:sitemap !-- lots of settings -- map:pipelines !-- lots of pipeline settings -- !-- For a VERY simple test, just add the below four lines -- !-- This will cause any errors to display the error.html file and throw an HTTP 404 response -- map:handle-errors map:generate src=error.html/ map:serialize type=html status-code=404/ /map:handle-errors /map:pipelines /map:sitemap Tried this, still no change in the error behiavor, I am seeing the output filtered through exception2html. The actual Cocoon error may be informative, it seems to be coming from the top-level sitemap.xmap (i.e. the xmlui one, not the Mirage one), it says failed to process reader, and has a complaint line 605 and 606 of host/dspace/xmlui/sitemap.xmap. Is this helpful? -- A. 4. You may need to restart Tomcat (depending on your settings) 5. Finally, test some invalid URLs. For me, DSpace XMLUI is running directly at http://localhost:8080;. So, all of these invalid URLs show me the error.html contents:
Re: [Dspace-tech] More enterprise deployment questions
Hi Andrew, On 1/23/2014 5:28 PM, Andrew Reid wrote: I have two new requirements I have to try to comply with. The first is, the security folks would like me to not expose tracebacks when Java errors occur. I have followed various web guidelines for redirecting errors to a static error page, but I can't seem to figure out how to get dspace/xmlui to direct to it. I put the error page in static/error.html, and when I manually go to url/dspace/xmlui/error.html, I see my content. I then added this stanza: error-page excpetion-typejava.lang.Throwable/exception-type location/error.html/location /error-page ... to the web.xml file under WEB-INF for the dspace xmlui web app. The result of this is that I get HTTP Status 404 from Tomcat for any nontrivial dspace/xmlui URL, including the log-in page. (The static URL dspace/xmlui/error.html still works, though!) This is actually a tough one. It sounds directly related to a known bug: https://jira.duraspace.org/browse/DS-1596 By default, Apache Cocoon (which DSpace XMLUI uses) is capturing handling any errors. This is controlled in the sitemap.xmap: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/sitemap.xmap#L684 By default, what happens is that DSpace XMLUI reformats the Cocoon XML error via the included exception2html.xslt: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/exception2html.xslt This 'exception2html.xslt' is what creates the ugly Java stacktrace error page. So, you could directly modify this XSLT to change the look of the error page (and also hide the Java stacktrace). Unfortunately, because Cocoon is catching the error, I'm not sure it is being properly passed up to Tomcat (which might be what you are seeing, it's hard to tell). For DSpace, we actually had to manually apply a patch to Apache Cocoon to get it to even properly throw HTTP 404 Error Codes (as the latest version of Cocoon doesn't do it properly). Essentially, I suspect part of the problem here is in Apache Cocoon (but admittedly it's been a while since I've been able to dig in deeply here). There's more background info on XMLUI error page issues in that ticket I've linked above. If you (or anyone else listening in) manage to find a better solution, I think we'd all like to hear it! The second requirement is, I have been asked to turn off password autocomplete. This involves setting 'autocomplete=off' in the log-in form, but I am having some difficulty navigating the code-base -- I'm looking for a low-intervention way of doing this, to avoid having my DSpace being too different from the upstream, and ideally would like to do this *just* for the LDAP log-in form. Is there a simple way to do this, or should I just keep looking? In the XMLUI, the actual HTML is generated via the XSLTs in the theme you are using. So, the answer to this depends on your *theme*. By default, DSpace XMLUI uses the Mirage theme, which itself loads up the 'dr2xhtml-alt' base theme for most of the basic XSLT stylesheets. If you are using Mirage / dri2xhtml-alt, then the XSLT template which creates *all* forms can be found here: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/themes/dri2xhtml-alt/core/elements.xsl#L90 If you *only* want to set autocomplete='off' for the LDAP login form, you likely could add a simple xsl:if into this template...something like: form ... xsl:if test=@id='aspect.eperson.LDAPLogin.div.login' xsl:attribute name=autocompleteoff/xsl:attribute /xsl:if ... /form NOTE: I'm *guessing* at the proper @id value here. I don't have an LDAP enabled site to look at. But, you should be able to find the @id value by browsing to your LDAP login page, and adding ?XML on the end of the URL. What you will then see is the underlying XML of that page (which the XSLT then transforms to XHTML obviously). You want to find the value of the @id attribute on the div interactive='yes' (that XML div tag gets changed to an HTML form tag). Hopefully that helps! - Tim -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] More enterprise deployment questions
Hi Andrew (and all), A followup on your custom error page question: After digging into the code again today, I just figured out a workaround where you *can* use a static HTML error page. I've described it in this comment on DS-1596: https://jira.duraspace.org/browse/DS-1596?focusedCommentId=32607 I also now have a theory for how we *should* be able to fix this in DSpace so that your DSpace theme is applied. But, I think that'll take a bit more time to implement, so for now, the workaround should be good enough for your needs. - Tim On 1/24/2014 10:58 AM, Tim Donohue wrote: Hi Andrew, On 1/23/2014 5:28 PM, Andrew Reid wrote: I have two new requirements I have to try to comply with. The first is, the security folks would like me to not expose tracebacks when Java errors occur. I have followed various web guidelines for redirecting errors to a static error page, but I can't seem to figure out how to get dspace/xmlui to direct to it. I put the error page in static/error.html, and when I manually go to url/dspace/xmlui/error.html, I see my content. I then added this stanza: error-page excpetion-typejava.lang.Throwable/exception-type location/error.html/location /error-page ... to the web.xml file under WEB-INF for the dspace xmlui web app. The result of this is that I get HTTP Status 404 from Tomcat for any nontrivial dspace/xmlui URL, including the log-in page. (The static URL dspace/xmlui/error.html still works, though!) This is actually a tough one. It sounds directly related to a known bug: https://jira.duraspace.org/browse/DS-1596 By default, Apache Cocoon (which DSpace XMLUI uses) is capturing handling any errors. This is controlled in the sitemap.xmap: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/sitemap.xmap#L684 By default, what happens is that DSpace XMLUI reformats the Cocoon XML error via the included exception2html.xslt: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/exception2html.xslt This 'exception2html.xslt' is what creates the ugly Java stacktrace error page. So, you could directly modify this XSLT to change the look of the error page (and also hide the Java stacktrace). Unfortunately, because Cocoon is catching the error, I'm not sure it is being properly passed up to Tomcat (which might be what you are seeing, it's hard to tell). For DSpace, we actually had to manually apply a patch to Apache Cocoon to get it to even properly throw HTTP 404 Error Codes (as the latest version of Cocoon doesn't do it properly). Essentially, I suspect part of the problem here is in Apache Cocoon (but admittedly it's been a while since I've been able to dig in deeply here). There's more background info on XMLUI error page issues in that ticket I've linked above. If you (or anyone else listening in) manage to find a better solution, I think we'd all like to hear it! The second requirement is, I have been asked to turn off password autocomplete. This involves setting 'autocomplete=off' in the log-in form, but I am having some difficulty navigating the code-base -- I'm looking for a low-intervention way of doing this, to avoid having my DSpace being too different from the upstream, and ideally would like to do this *just* for the LDAP log-in form. Is there a simple way to do this, or should I just keep looking? In the XMLUI, the actual HTML is generated via the XSLTs in the theme you are using. So, the answer to this depends on your *theme*. By default, DSpace XMLUI uses the Mirage theme, which itself loads up the 'dr2xhtml-alt' base theme for most of the basic XSLT stylesheets. If you are using Mirage / dri2xhtml-alt, then the XSLT template which creates *all* forms can be found here: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/themes/dri2xhtml-alt/core/elements.xsl#L90 If you *only* want to set autocomplete='off' for the LDAP login form, you likely could add a simple xsl:if into this template...something like: form ... xsl:if test=@id='aspect.eperson.LDAPLogin.div.login' xsl:attribute name=autocompleteoff/xsl:attribute /xsl:if ... /form NOTE: I'm *guessing* at the proper @id value here. I don't have an LDAP enabled site to look at. But, you should be able to find the @id value by browsing to your LDAP login page, and adding ?XML on the end of the URL. What you will then see is the underlying XML of that page (which the XSLT then transforms to XHTML obviously). You want to find the value of the @id attribute on the div interactive='yes' (that XML div tag gets changed to an HTML form tag). Hopefully that helps! - Tim -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In
Re: [Dspace-tech] More enterprise deployment questions
On Fri, Jan 24, 2014 at 12:11:38PM -0600, Tim Donohue wrote: Hi Andrew (and all), A followup on your custom error page question: After digging into the code again today, I just figured out a workaround where you *can* use a static HTML error page. I've described it in this comment on DS-1596: https://jira.duraspace.org/browse/DS-1596?focusedCommentId=32607 Thanks, this looks useful -- I take it that I can just make the suggested changes, and/but don't have to remove the error-handling stuff from sitemap.xmap? It looks much better than vandalizing the exception2html.xslt stylesheet, and for my case specifically, having the changes be in the theme directory is handy, since that's where my other customizations already live. -- A. I also now have a theory for how we *should* be able to fix this in DSpace so that your DSpace theme is applied. But, I think that'll take a bit more time to implement, so for now, the workaround should be good enough for your needs. - Tim On 1/24/2014 10:58 AM, Tim Donohue wrote: Hi Andrew, On 1/23/2014 5:28 PM, Andrew Reid wrote: I have two new requirements I have to try to comply with. The first is, the security folks would like me to not expose tracebacks when Java errors occur. I have followed various web guidelines for redirecting errors to a static error page, but I can't seem to figure out how to get dspace/xmlui to direct to it. I put the error page in static/error.html, and when I manually go to url/dspace/xmlui/error.html, I see my content. I then added this stanza: error-page excpetion-typejava.lang.Throwable/exception-type location/error.html/location /error-page ... to the web.xml file under WEB-INF for the dspace xmlui web app. The result of this is that I get HTTP Status 404 from Tomcat for any nontrivial dspace/xmlui URL, including the log-in page. (The static URL dspace/xmlui/error.html still works, though!) This is actually a tough one. It sounds directly related to a known bug: https://jira.duraspace.org/browse/DS-1596 By default, Apache Cocoon (which DSpace XMLUI uses) is capturing handling any errors. This is controlled in the sitemap.xmap: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/sitemap.xmap#L684 By default, what happens is that DSpace XMLUI reformats the Cocoon XML error via the included exception2html.xslt: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/exception2html.xslt This 'exception2html.xslt' is what creates the ugly Java stacktrace error page. So, you could directly modify this XSLT to change the look of the error page (and also hide the Java stacktrace). Unfortunately, because Cocoon is catching the error, I'm not sure it is being properly passed up to Tomcat (which might be what you are seeing, it's hard to tell). For DSpace, we actually had to manually apply a patch to Apache Cocoon to get it to even properly throw HTTP 404 Error Codes (as the latest version of Cocoon doesn't do it properly). Essentially, I suspect part of the problem here is in Apache Cocoon (but admittedly it's been a while since I've been able to dig in deeply here). There's more background info on XMLUI error page issues in that ticket I've linked above. If you (or anyone else listening in) manage to find a better solution, I think we'd all like to hear it! The second requirement is, I have been asked to turn off password autocomplete. This involves setting 'autocomplete=off' in the log-in form, but I am having some difficulty navigating the code-base -- I'm looking for a low-intervention way of doing this, to avoid having my DSpace being too different from the upstream, and ideally would like to do this *just* for the LDAP log-in form. Is there a simple way to do this, or should I just keep looking? In the XMLUI, the actual HTML is generated via the XSLTs in the theme you are using. So, the answer to this depends on your *theme*. By default, DSpace XMLUI uses the Mirage theme, which itself loads up the 'dr2xhtml-alt' base theme for most of the basic XSLT stylesheets. If you are using Mirage / dri2xhtml-alt, then the XSLT template which creates *all* forms can be found here: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/themes/dri2xhtml-alt/core/elements.xsl#L90 If you *only* want to set autocomplete='off' for the LDAP login form, you likely could add a simple xsl:if into this template...something like: form ... xsl:if test=@id='aspect.eperson.LDAPLogin.div.login' xsl:attribute name=autocompleteoff/xsl:attribute /xsl:if ... /form NOTE: I'm *guessing* at the proper @id value here. I don't have an LDAP enabled site to look at. But, you should be able to find the @id value by browsing to your LDAP login page, and adding ?XML on the end of the URL. What you will
Re: [Dspace-tech] More enterprise deployment questions
Hi Andrew, On 1/24/2014 12:35 PM, Andrew Reid wrote: Thanks, this looks useful -- I take it that I can just make the suggested changes, and/but don't have to remove the error-handling stuff from sitemap.xmap? That is correct. The static error page workaround suggested in https://jira.duraspace.org/browse/DS-1596 will actually *override* the default error-handling stuff in the main sitemap.xmap. So, you can (and should) leave those defaults in place. That way, if your static HTML error page was ever accidentally inaccessible (e.g. it was accidentally moved/deleted/permissions wrong), then the default (not so pretty) DSpace error page would take back over. - Tim -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] More enterprise deployment questions
On Fri, Jan 24, 2014 at 01:58:53PM -0600, Tim Donohue wrote: Hi Andrew, On 1/24/2014 12:35 PM, Andrew Reid wrote: Thanks, this looks useful -- I take it that I can just make the suggested changes, and/but don't have to remove the error-handling stuff from sitemap.xmap? That is correct. The static error page workaround suggested in https://jira.duraspace.org/browse/DS-1596 will actually *override* the default error-handling stuff in the main sitemap.xmap. So, you can (and should) leave those defaults in place. That way, if your static HTML error page was ever accidentally inaccessible (e.g. it was accidentally moved/deleted/permissions wrong), then the default (not so pretty) DSpace error page would take back over. Huh. This is not working for me -- I have a testing installation with the default Mirage theme, and I am adding the lines from your comment directly in Mirage/sitemap.xmap, rather than rebuilding the app -- I mention this because it might be part of the issue. I may be using weird errors, too, my testing URL is host/dspace/xmlui/static/wrong.html, or host/dspace/xmlui/static/wrong.js -- they give different errors, the former gives a ResourceNotound with a big long Cocoon back-trace, and the second one gives a NullPointerException, with a very short Cocoon back-trace. Modifying Mirage/sitemap.xmap did not change this behavior -- I double-checked that the additional handle-errors map is *inside* the map:pipelines tag and *outside* any of the other map:item tag-pairs. Are my errors too weird? Am I actually getting *two* errors somehow? Vandalizing the top-level sitemap.xml is starting to look like the near-term solution, but I'd be willing to invest a bit more effort in a nicer answer. -- A. -- Dr. Andrew C. E. Reid Physical Scientist, Computer Operations Administrator Center for Theoretical and Computational Materials Science National Institute of Standards and Technology, Mail Stop 8555 Gaithersburg MD 20899 USA andrew.r...@nist.gov -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] More enterprise deployment questions
Hi Andrew, On 1/24/2014 2:46 PM, Andrew Reid wrote: Huh. This is not working for me -- I have a testing installation with the default Mirage theme, and I am adding the lines from your comment directly in Mirage/sitemap.xmap, rather than rebuilding the app -- I mention this because it might be part of the issue. I may be using weird errors, too, my testing URL is host/dspace/xmlui/static/wrong.html, or host/dspace/xmlui/static/wrong.js -- they give different errors, the former gives a ResourceNotound with a big long Cocoon back-trace, and the second one gives a NullPointerException, with a very short Cocoon back-trace. Modifying Mirage/sitemap.xmap did not change this behavior -- I double-checked that the additional handle-errors map is *inside* the map:pipelines tag and *outside* any of the other map:item tag-pairs. Are my errors too weird? Am I actually getting *two* errors somehow? Vandalizing the top-level sitemap.xml is starting to look like the near-term solution, but I'd be willing to invest a bit more effort in a nicer answer. I'm probably going to need more info. It sounds like our two setups are different in some waythough admittedly, all of this work is extremely new (working on it *today*). So maybe I've overlooked something too. What does the URL to your DSpace homepage look like? Is it host/dspace/xmlui/? Also, what happens if you remove the /static/ subpath? (That actually *IS* a valid subpath in DSpace, and there's some special logic to deal with that subpath which could be causing issues here.) In any case, here's what works for me (on DSpace 4.0, but it should be the same for 3.2). In the example below [dspace.dir] represents the directory where DSpace is *installed*. 1. For me, Tomcat is loading the DSpace XMLUI from [dspace.dir]/webapps/xmlui/ (it's a completely fresh install of DSpace 4) 2. Create an error.html under [dspace.dir]/webapps/xmlui/themes/Mirage/ (making sure it's obviously readable to Tomcat) 3. Modify the sitemap.xmap under [dspace.dir]/webapps/xmlui/themes/Mirage/ For a simple test just add this: map:sitemap !-- lots of settings -- map:pipelines !-- lots of pipeline settings -- !-- For a VERY simple test, just add the below four lines -- !-- This will cause any errors to display the error.html file and throw an HTTP 404 response -- map:handle-errors map:generate src=error.html/ map:serialize type=html status-code=404/ /map:handle-errors /map:pipelines /map:sitemap 4. You may need to restart Tomcat (depending on your settings) 5. Finally, test some invalid URLs. For me, DSpace XMLUI is running directly at http://localhost:8080;. So, all of these invalid URLs show me the error.html contents: http://localhost:8080/asdfasdf http://localhost:8080/not/a/valid/path http://localhost:8080/also/not/valid.html http://localhost:8080/handle/not/valid http://localhost:8080/asdfsdf.js But, I can still load valid DSpace URLs like: http://localhost:8080/ (DSpace homepage for me) http://localhost:8080/community-list (Community listing) I'm not sure if that helps at all. But, hopefully it gives you all the steps. Obviously I've simplified the map:handle-errors setting (from the more complete example in DS-1596). - Tim -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
[Dspace-tech] More enterprise deployment questions
Hi again all -- I'm continuing to struggle with complying with enterprise security policy. I am using DSpace 3.2, serving xmlui, with the Apache JSPUI connector. I have two new requirements I have to try to comply with. The first is, the security folks would like me to not expose tracebacks when Java errors occur. I have followed various web guidelines for redirecting errors to a static error page, but I can't seem to figure out how to get dspace/xmlui to direct to it. I put the error page in static/error.html, and when I manually go to url/dspace/xmlui/error.html, I see my content. I then added this stanza: error-page excpetion-typejava.lang.Throwable/exception-type location/error.html/location /error-page ... to the web.xml file under WEB-INF for the dspace xmlui web app. The result of this is that I get HTTP Status 404 from Tomcat for any nontrivial dspace/xmlui URL, including the log-in page. (The static URL dspace/xmlui/error.html still works, though!) I've tried numerous variations on the path in the location/location in that stanza, with and without the static part, with and without the leading slash, and with various other pieces of the path, but they all give me a Tomact-404. What's the right way to do this? I am hoping to be able to show a simple static page, but will be happy with anything that works. The second requirement is, I have been asked to turn off password autocomplete. This involves setting 'autocomplete=off' in the log-in form, but I am having some difficulty navigating the code-base -- I'm looking for a low-intervention way of doing this, to avoid having my DSpace being too different from the upstream, and ideally would like to do this *just* for the LDAP log-in form. Is there a simple way to do this, or should I just keep looking? Thanks in advance -- as you may have discerned, I'm more of a sysadmin, my Java and Tomcat skills are not as strong as they maybe should be for this kind of thing. -- A. -- Dr. Andrew C. E. Reid Physical Scientist, Computer Operations Administrator Center for Theoretical and Computational Materials Science National Institute of Standards and Technology, Mail Stop 8555 Gaithersburg MD 20899 USA andrew.r...@nist.gov -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] More enterprise deployment questions
On Thu, Jan 23, 2014 at 05:50:53PM -0500, Andrew Reid wrote: Hi again all -- I'm continuing to struggle with complying with enterprise security policy. I am using DSpace 3.2, serving xmlui, with the Apache JSPUI connector. Replying to myself to call out and correct a rather confusing error there -- I am using the Aapche mod_jk connector. My DSpace interface is xmlui. Jspui is not relevant to this discussion. -- A. I have two new requirements I have to try to comply with. The first is, the security folks would like me to not expose tracebacks when Java errors occur. I have followed various web guidelines for redirecting errors to a static error page, but I can't seem to figure out how to get dspace/xmlui to direct to it. I put the error page in static/error.html, and when I manually go to url/dspace/xmlui/error.html, I see my content. I then added this stanza: error-page excpetion-typejava.lang.Throwable/exception-type location/error.html/location /error-page ... to the web.xml file under WEB-INF for the dspace xmlui web app. The result of this is that I get HTTP Status 404 from Tomcat for any nontrivial dspace/xmlui URL, including the log-in page. (The static URL dspace/xmlui/error.html still works, though!) I've tried numerous variations on the path in the location/location in that stanza, with and without the static part, with and without the leading slash, and with various other pieces of the path, but they all give me a Tomact-404. What's the right way to do this? I am hoping to be able to show a simple static page, but will be happy with anything that works. The second requirement is, I have been asked to turn off password autocomplete. This involves setting 'autocomplete=off' in the log-in form, but I am having some difficulty navigating the code-base -- I'm looking for a low-intervention way of doing this, to avoid having my DSpace being too different from the upstream, and ideally would like to do this *just* for the LDAP log-in form. Is there a simple way to do this, or should I just keep looking? Thanks in advance -- as you may have discerned, I'm more of a sysadmin, my Java and Tomcat skills are not as strong as they maybe should be for this kind of thing. -- A. -- Dr. Andrew C. E. Reid Physical Scientist, Computer Operations Administrator Center for Theoretical and Computational Materials Science National Institute of Standards and Technology, Mail Stop 8555 Gaithersburg MD 20899 USA andrew.r...@nist.gov -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Dr. Andrew C. E. Reid Physical Scientist, Computer Operations Administrator Center for Theoretical and Computational Materials Science National Institute of Standards and Technology, Mail Stop 8555 Gaithersburg MD 20899 USA andrew.r...@nist.gov -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
