Hi, I have a site using S3 and SSL and it seems that most of the Omeka helper functions return a non-HTTPS file path, which causes mixed-content warnings. I don’t have direct access to the AWS account, but is this something that needs to be configured at the account level or is there some way to specify SSL in config.ini or elsewhere in Omeka?
You can specify endpoint in the S3 part of config.ini as an adapter option… specifying the https URL, like https://s3.amazonaws.com should do the trick.
Hi @jflatnes, it seems that just adding HTTPS to the front of the storage.adapterOptions.endpoint URL doesn’t work. I’ve been in touch with the account admin who is looking at configuring SSL via Cloudfront. I don’t have access to look at the account options, but if you have ideas about how to proceed, I’ll pass them on. Thanks – E
I’ve tried a couple variations on the custom endpoint, which all cause errors on file upload/delete.
Adding https://[bucket].s3-website-us-east-1.amazonaws.com as the custom endpoint…
Zend_Http_Client_Adapter_Exception
Unable to Connect to ssl://[bucket][bucket].s3-website-us-east-1.amazonaws.com:443.
Error #110: Connection timed out
Zend_Http_Client_Adapter_Exception
Unable to Connect to ssl://lorain.local.history.amazonaws.com:443.
Error #0: php_network_getaddresses: getaddrinfo failed: Name or service not known
Have you tried https://s3.amazonaws.com ? And of course making sure that you can make outgoing SSL connections generally, as a firewall/configuration matter. Usually that’s not an issue, though.
Was the error really just Error #0: ? Or was there some more text there? You might just have an issue with the SSL setup on that server for making outgoing connections. An “error #0” with nothing else is a pretty typical symptom of that kind of problem; often the cause is that PHP just doesn’t know where the SSL certificates are located (fixable with a php.ini setting openssl.cafile or openssl.capath).
Anyway, S3 itself will let you access the files through HTTPS just fine so it’s really just a matter of getting the adapter to emit HTTPS URLs. Changing the endpoint will change the emitted URLs since they’re created by using the endpoint as a basis, but as you’ve seen that also changes how the connection is made for uploading and deleting files.
As a workaround you could just force the URL generated to be HTTPS by changing the uri line in Omeka_Storage_Adapter_ZendS3::getUri():
$uri = 'https:' . substr("$endpoint/$object", 5);
You could also do that in a plugin by just extending the ZendS3 adapter, overriding just getUri() and doing a similar substr-and-prepend to the uri you’d get from calling parent::getUri().
Probably… although for a solution going into the core we’d probably need to be a little more clever about it. Minimally, we’d need to account for an endpoint that’s already https (even though that didn’t work in your case).