Flash player not installed - but it is

[nuno.e.f...@gmail.com]

Hi all,

I have VirtualBox with Atom 2.4.0 running on my PC and I'm able to run the "Import multiple digital objects" feature. This means, it is using the flash player in the Chrome browser.

Meanwhile, it was installed the 2.4.1 version on a new machine (not VirtualBox) and the same functionality is no longer working.

We are always getting the message "Your browser does not have Flash player installed. To import digital objects, please Download Adobe Flash Player (requires version 9.0.45 or higher)". However, we are using the latest version of Flash (31.0.0.153), we have set the Flash support to allow, and we are using the same Chrome browser. It doesn't work either with Firefox.

See the attached file.

I assume this is an issue on the client side (flash player detection!?).

Any help on this?

Thanks,

Nuno Carvalho

[Dan Gillean]

Hi Nuno, 

If it's there, can you try clicking on the plugin icon next to the URL in Chrome's address bar? I have found in the past that sometimes the site is waiting for permission to use Flash, but Chrome doesn't make this very obvious. I too am hoping this is just a client-side issue with allowing Flash! Note that you may need to refresh the page after approving. 

Let me know what you find! 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
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 post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/96b7210a-a5ab-4ca2-85a2-5820cf1f4032%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nuno Carvalho]

Hi Dan,
Thanks for your feedback.
Please see the attached screenshot.
All permissions are granted and page is reload as suggested by Chrome.

In some way I'm confident this is not a problem on my browser+flash plugin since it works with Atom 2.4.0, after giving the required permissions. Doing the same steps on 2.4.1 it won't work.

The 2.4.0 is the virtualbox image provided by you.
The 2.4.1 was a fresh install. I assume this is not related with any software dependency that is missing or lower version.
Is there any code change on Atom 2.4.1 regarding flash detection on browser that could bring this issue?

Thanks,
Nuno

You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/u5nHWhOZoOE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ica-atom-user...@googlegroups.com.

To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZLEWDPujaFHgEjYXvB-hEwra-X-Dm7Y%3Dheb6_Kh_p%3D%2Bjg%40mail.gmail.com.

[Dan Gillean]

Hi Nuno, 

Strange! I can't think of anything we've changed in 2.4.1 that should affect this. You can see a list of all the 2.4.1 issues here: 

• https://projects.artefactual.com/projects/atom/issues?fixed_version_id=122&set_filter=1&status_id=c
  

I am just wrapping up my day now, but will try to check in with our development team tomorrow to see if they have any thoughts. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

[Nuno]

Hi Dan,

Any thoughts on this?

Thanks,

Nuno

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZJkO5fZk45Uku5k3Sci_AZGZLQ_nrmeb8F_ssUekBeCrA%40mail.gmail.com.

[Dan Gillean]

Hi Nuno, 

I'm at a bit of a loss. I've tested this in my 2.4 and 2.5 vagrant boxes, as well as on a server-installed version of 2.4.1, using Ubuntu 14.04. In each case, the Upload digital objects functionality worked for me, after I had allowed Flash in Chrome and reloaded the page. 

I checked with one developer who had no further ideas, and I'm just waiting for one more to get back to me, to see if anything might occur to him. Hopefully he might have some suggestions! 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/AC739086-19CF-4E84-B9A0-2DFF478050BA%40gmail.com.

[Nuno Carvalho]

Hi Dan,
Please see the logs below obtained from the web browser console.
I get lots of similar messages complaining about security issues?
In the end, Atom seems to be looking the SWF file from a wrong location.

Hope this could be of any help.


-----cut here---
Navigated to https://mysite.com/index.php/fundo_xpto/multiFileUpload
modernizr.js:4 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-CwE3Bg0VYQOIdNAkbB/Btdkhul49qZuwgNCMPgNY5zw='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

y @ modernizr.js:4
s.touch @ modernizr.js:4
(anonymous) @ modernizr.js:4
(anonymous) @ modernizr.js:4
modernizr.js:4 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-MZKTI0Eg1N13tshpFaVW65co/LeICXq4hyVx6GWVlK0='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

y @ modernizr.js:4
s.csstransforms3d @ modernizr.js:4
(anonymous) @ modernizr.js:4
(anonymous) @ modernizr.js:4
modernizr.js:4 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-LpfmXS+4ZtL2uPRZgkoR29Ghbxcfime/CsD/4w5VujE='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

y @ modernizr.js:4
s.fontface @ modernizr.js:4
(anonymous) @ modernizr.js:4
(anonymous) @ modernizr.js:4
modernizr.js:4 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-YJO/M9OgDKEBRKGqp4Zd07dzlagbB+qmKgThG52u/Mk='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

y @ modernizr.js:4
s.generatedcontent @ modernizr.js:4
(anonymous) @ modernizr.js:4
(anonymous) @ modernizr.js:4
multiFileUpload:46 Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-XQSCpycGlQ/TCkPBfFho8/VzX2Yd/ju09dEt6abX8M8='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

multiFileUpload:62 Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-TBKxViw4fmnOv1c+rrQJu0ERA6FKtbvt/9k6IJJpBso='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

multiFileUpload:427 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-biLFinpqYMtWHmXfkA1BPeCY0/fNt46SAZ+BBk5YUog='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

multiFileUpload:440 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-ZdHxw9eWtnxUb3mk6tBS+gIiVUPE3pGM470keHPDFlE='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

multiFileUpload:479 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-q5rmgt0qnS6vusTX681CxP1llW8fGLSs67L4+dVXYgM='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

multiFileUpload:481 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-U1dTjUY5CFSoYbVbko3PIYFvQ53kaUhoQlKi6MYm11s='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

multiFileUpload:482 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-Xe4z8fPUKiEOmL6fVMXtbZo4ymd976D7yIGL4Wjv9eA='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

multiFileUpload:1 Refused to load the image 'https://www.gravatar.com/avatar/bf2e3bdd3d0478277c75300da929bbcf?s=25' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.

multiFileUpload:503 Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-qUo05uEWPhWHwns9zmJn+UUgsHQ+LU+b+eKaB7GB668='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

uploader-min.js:8 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-6wRdeNJzEHNIsDAMAdKbdVLWIqu8b6+Bs+xVNZqplQw='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

write @ uploader-min.js:8
_embedSWF @ uploader-min.js:9
YAHOO.widget.FlashAdapter @ uploader-min.js:9
YAHOO.widget.Uploader @ uploader-min.js:9
attach @ multiFileUpload.js:9
(anonymous) @ drupal.js:56
each @ jquery.js:2
Drupal.attachBehaviors @ drupal.js:54
(anonymous) @ drupal.js:349
l @ jquery.js:2
fireWith @ jquery.js:2
ready @ jquery.js:2
A @ jquery.js:2
uploader.swf:1 GET https://mysite.com/index.php/fundo_xpto/assets/uploader.swf 404 (Not Found)
----

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2BGqumy5qhVeOq-8uodvdyetkSLBktUDhk%2BQaSVhNeAiA%40mail.gmail.com.

[sbr...@artefactual.com]

Hi Nuno

Did you try clicking that "Download Adobe Flash Player" link shown on your original screenshot?  I seem to recall having seen that message before on new sites and have found that clicking that link re-confirms to the browser that Flash should be running.

See attached screenshot - I have highlighted the link in green.

Steve

[Nuno Carvalho]

Hi Steve,

The link opens the adobe website ("https://get.adobe.com/flashplayer/"). I have already installed plugin from there. The same browser is working for a Vangrant image but not for a new deployment.
As per the logs that I've sent, the multiFileUpload webpage seems to try to get the uploader.swf file from a wrong location, the reason I'm getting HTTP 404. I would assume, the problem is here. But don't know how to fix it.

Thanks,
Nuno

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/235b4549-c858-43d7-b0fe-482e69a1df69%40googlegroups.com.

[Nuno Carvalho]

Hi all,
Does the info below provide any relevant information for you?
Is it required to configure web server with any specific configuration?

Thanks,
Nuno

[Dan Gillean]

I'm sorry Nuno, we're coming up short on ideas. There shouldn't be anything in particular that you need to install or configure for the Flash uploader to work for a server installation of AtoM. 

I was unable to find the same errors in my Chrome browser tools, but I admit I'm not that familiar with using these dev tools so I might just be missing them. 

Have you tried accessing this page from a different computer and browser? Is there anything in your server set up that varies from our recommended installation? Are there additional security features on your server or in your network that could be blocking access to Flash?

One suggestion a developer had was that perhaps there is an issue related to the Content Security Policy in your browser, and it might be possible to tweak the HTTP server so the browser receives the right HTTP header to allow Flash content to manipulate the DOM. I can't advise you much on this front, but some general links for you to investigate: 

• https://scotthelme.co.uk/content-security-policy-an-introduction/
  
• https://developer.chrome.com/extensions/contentSecurityPolicy
  
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/plugin-types#Allowing_Flash_content
  

Just a thought. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/517f4eb0-fb87-80d4-3be3-59c3a1a7bd7a%40gmail.com.

[Nuno Carvalho]

Hi Dan,

Meanwhile is there any other alternative to upload a batch of photos at once?

Thanks,
Nuno

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZLsP_LJS_cRRxG0VbtkTd6fJnhr%3D%3DFiHMrOkBZT8puiag%40mail.gmail.com.

[Dan Gillean]

Hi Nuno, 

Yes, you can use either the CSV import, or the command-line Digital object load task. I will outline them both below. 

Meanwhile, I'm guessing this means that you haven't had any success in resolving the Flash issue? Did you ever test this from a different computer/browser? Did you investigate the CSP links I provided to see if they were helpful?

I assume you've already tried all of the following, but just in case, I also found this help page from Google on resolving Flash issues in Chrome: 

• https://support.google.com/chrome/answer/6258784
  

Below I'll provide further information on the alternative ways you might import multiple digital objects in AtoM until this issue is resolved. 

Using the CSV import to add digital objects

There are 2 fields you can add to the CSV for digital objects:

• digitalObjectPath
• digitalObjectURI

Both are used to link a single digital object to the current description. The digitalObjectPath column expects a file path to an object that you've added to your AtoM server. In this case, the objects must be on the same server as AtoM, in a directory accessible to you from there - so if your AtoM instance is installed at /usr/share/nginx/atom, you could create a temporary folder called images (for example) and add your digital objects there. In that case,  if you had an image in that folder called image01.jpg and you wanted to link it to a new description via CSV import, then your digitalObjectPath value might be /usr/share/nginx/atom/images/image01.jpg. It's been a minute since I tested this, but it's also possible you can just drop the absolute path, and just reference the subdirectory - i.e. you could try adding just images/image01.jpg to the digitalObjectPath column and see if that works. 

In contrast, the digitalObjectURI column is used to link to publicly accessible digital objects on the web. When this is done, AtoM will fetch the web version to create local derivatives (i.e. the reference display copy available on the description's view page, and the thumbnail in search/browse results), but it will not store a copy of the master object - instead, it will just save the URL pointing to it, and serve that link to users trying to access the master object via a browser. 

AtoM's requirements for being able to link to remote digital objects using this method are: 

• They must be web-accessible without any barriers to access (no logins, firewalls, VPNs, etc)
  
• They must be HTTP or HTTPS links (FTP links won't work)
  
• They must end in the file extension of the digital object. You can't link to a landing page, unfortunately. 
  

This last point means, for example, that you can't link directly to a YouTube video, for example - YouTube purposefully obfuscates  direct access to the actual movie file (aka the .mp4 or .avi file) so you can't download it directly by right-click and saving. If you were looking at an image on a webpage, you would generally want to right-click and select "View image" (or whatever your browser's equivalent option is) to see the direct path to the object that ends in .jpg, and this is the URL you'd want to use in the digitalObjectURI column. 

See: https://www.accesstomemory.org/docs/latest/user-manual/import-export/csv-import/#digital-object-related-import-columns

If you wanted to use the CSV import to add new item-level child descriptions to an existing description in AtoM and attach digital objects at the same time, you could prepare a CSV of your item-level descriptions (our templates are on the wiki here - there have been no changes to the template since the 2.3 release so that is the current one to use), and use one of the digital object columns to point to the related digital objects. 

To make your descriptions import as children of a target description in AtoM, you can use the qubitParentSlug column. This column expects the slug of the target parent description as the value to tell it where the new record should be created. More details here: 

• https://www.accesstomemory.org/docs/latest/user-manual/import-export/csv-import/#qubitparentslug
  

The second method for importing digital objects would be to first create the descriptions in AtoM, and then use the digitalobject:load command-line task to import them separately. 

Using the digital object load task to add digital objects

AtoM has a command-line task to load digital objects. Like the digitalObjectPath column in the CSV import, this task expects that you have previously added the images somewhere on the same server as your AtoM instance that is accessible from the command-line: generally i recommend creating a new temporary directory in the root AtoM installation directory (such as images, which you would create at /usr/share/nginx/atom if you've followed our recommended installation instructions), and adding your images there, so you know the filesystem permissions will be correctly inherited. 

 The task takes a simple CSV with 2 columns - the filename (which includes a full path to the digital object), and the second column should be either the identifier or the internal object ID of the target descriptions. 

You can read more information here: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/cli-import-export/#load-digital-objects-via-the-command-line
  

The drawback of this task is that the information object ID is not easy to look up - you need to use SQL to find it out for each description. The instructions above do provide some instructions on how to do this. If using the identifier, you need to make sure that every target identifier in AtoM is unique - so if your identifiers are NOT unique (e.g. you've used 01, 02, etc on multiple different descriptions), then there is the risk that AtoM will attach the object to the wrong description. 

I don't know why it was implemented this way - in the future I would like us to add slug as an option for this task, since this is easy to get without needing the command-line and always unique in AtoM - but it's not there now. So, this is option 1, though it does require some work to properly prepare the accompanying CSV. 

Hope this helps! 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/6aacb5a6-72c5-0f67-c398-c09c9316c0d7%40gmail.com.

[Nuno Carvalho]

Hi Dan,
The Flash problem is a server-side issue.
I was able to replicate the issue by adding the following line to the nginx configuration:

add_header Content-Security-Policy "default-src 'self';

Your vagrant image does not have such configuration, the reason why it was working and not in our production environment.

Thanks for the explanation on the alternative import processes.

Best regards,
Nuno

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZLsZdj9Yu-MY8FOcD_DT_Dpf14_%3Dwe_brFzT8-1Xa5E2A%40mail.gmail.com.

[Dan Gillean]

Hi Nuno, 

I'm so glad to hear you've figured it out! Thanks for updating the thread and letting us know what worked for you. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/c742316f-67d2-a1f2-f197-710b876161f7%40gmail.com.