Skip to first unread message
Stephen Harding
Feb 22, 2022, 6:49:53 AM2/22/22
to AtoM Users
This may be one for the developers as a potential bug fix, or maybe I'm doing something wrong (which is entirely possible!).
When viewing a non-published record, e.g.collection, and logged in (so I'm allowed to see it in draft) I then click on either DC or EAD XML. It then takes me to the generated XML within the browser. If I then were to save this page it adds to the download queue but then the file is "Deleted" from downloads straight away.
Initially I had suspected this was down to anti-virus polices within our organisation but then tested it on personal devices using different OS's and browsers. When doing some more testing I found that it was doing this deleting only when exporting draft records. Perhaps some kind of issue with my authenticated session not being passed to the download...?
I checked here but couldn't see anything telling me what I was trying to do was a known no-no.
At least we know of the work-around (publish or CLI) but thought it may be worth posting still.
Happy to provide more details...
Cheers
Stephen
Dan Gillean
Feb 22, 2022, 10:41:57 AM2/22/22
to ICA-AtoM Users
Hi Stephen,
Saving the on-screen XML data shown is entirely handled by your browser and local computer - any permission checks in AtoM for draft records would take place before that, in determining whether or not you can get to the view page (and possibly whether or not you can see the XML when clicking the Export EAD or DC XML links). I did a quick test on our demo site with this record's EAD, which you'll have to be logged in to access:
I was able to download the file locally, using the "Save as" option in the right-click context menu of my browser (i.e. right clicking when on the XML page and then selecting "Save as".
Are you able to do this on the demo site?
It may still be some local configuration or permissions issue at play.
Cheers,
he / him
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/bac3d4a8-7234-49a7-b4b2-c89ad41c3a36n%40googlegroups.com.
Stephen Harding
Mar 1, 2022, 10:57:12 AM3/1/22
to AtoM Users
Hi Dan,
My initial thought was that it would be perhaps caused by an institutionally-controlled Chrome or anti-virus software. But I've tried on several different machines, including my standalone Macbook using both our AtoM installation and also your demo site.
Here's what happens - https://screencast-o-matic.com/watch/c3eVoHVbMCB
It happens on Edge too (not that I'd ever use it!) though I know that uses the Chrome engine. It does however work fine with Safari. I wonder whether it's an issue with a specific version of Chrome (Version 98.0.4758.109) that only happens with a specific version of AtoM?
Incidentally, I notice that when trying another institution's AtoM XML download we see different URL formats altogether, e.g. https://borthcat.york.ac.uk/downloads/exports/ead/3f06bd9478305a76e01def50c768d292.ead.xml compared to e.g. https://demo.accesstomemory.org/terry-copp-fonds;ead?sf_format=xml. Perhaps this is something they've configured differently, but it work's under the same test as above.
Hope this is useful,
Many thanks
Stephen
Dan Gillean
Mar 2, 2022, 10:42:58 AM3/2/22
to ICA-AtoM Users
Hi Stephen,
Interesting - thanks for the video. I still think this is something local - either a browser policy or a Windows one, as I can download the EAD XML from the Terry Copp fonds without issue.
I have one theory - I noticed that the Terry Copp fonds has two external URIs in the body of the description that use HTTP instead of HTTPS. As of more recent versions of Chrome, I believe the default browser policy is to block downloads from mixed content sources. See:
It's likely that other browsers have followed suit.
Does the same thing happen on this draft record in the demo site?
Otherwise, I'm not exactly sure what's different in my browser or Windows policies, but in my Chrome settings under Security and privacy, I currently have only Standard protection on Safe Browsing enabled (not enhanced), and I also do not have the setting to "Always use secure connections" enabled. Does changing any of these policies in your Chrome browser change anything?
It could also be a configuration in your local computer - something in the antivirus, or in the Windows Storage Sense settings. I'd try searching the web for further ideas - there's nothing in AtoM's code leading to this behavior, so there's no clear way for us to add a fix.
Incidentally, I notice that when trying another institution's AtoM XML download we see different URL formats altogether, e.g. https://borthcat.york.ac.uk/downloads/exports/ead/3f06bd9478305a76e01def50c768d292.ead.xml compared to e.g. https://demo.accesstomemory.org/terry-copp-fonds;ead?sf_format=xml. Perhaps this is something they've configured differently, but it work's under the same test as above.
Currently, XML files are generated in the browser synchronously on demand. For very large hierarchies, this can lead to the web browser timing out before the full EAD XML record is generated, meaning end users cannot download the file. One way some users avoid this is to enable a setting that will pre-generate XML files and cache them, so they can be served immediately on request, instead of being generated. These are stored in an exports subdirectory of the downloads directory in AtoM, and is what you're seeing on the Borthwick AtoM site. For more information, see:
Cheers,
he / him
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/7f047353-d04b-4f7d-849a-d90552b9f10en%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages