I am trying to implement the IIIF standard in order to show some papyri. I have configured Loris as an image server (here there is an info.json example: https://philhist-papyri-01.philhist.unibas.ch/loris/1/images/1.RectoIliad19th(T)book-IR-enh.jpg/info.json) and also I have configured Mirador. I am also serving manifests via an API (example: https://philhist-papyri-01.philhist.unibas.ch/api/iiif/11b4ca60-6bac-11eb-a1e6-005056b34690/manifest).
When I try to load the images in Mirador, I am getting an error:
Tile push../node_modules/openseadragon/build/openseadragon/openseadragon.js.$.Tile failed to load: https, https://philhist-papyri-01.philhist.unibas.ch, philhist-papyri-01.philhist.unibas.ch/6%2Fimages%2F6.VersoUnidentifiedLiteraryText-IR.jpg/full/4,/0/default.jpg - error: Image load aborted
Does anybody have any idea why this is coming from? The image actually can be retrieved from the URI in the manifest (https://philhist-papyri-01.philhist.unibas.ch/loris/1/images/1.RectoIliad19th(T)book-IR-enh.jpg/full/full/0/default.jpg), but it is not being shown in the mirador window.
There might be an issue with the resolver of Loris which is causing the #id of the image not to be canonical, but I am not quite sure.
I'm seeing an issue that perhaps CORS is not enabled for your info.json responses.
See: https://projectmirador.org/embed/?iiif-content=https://philhist-papyri-01.philhist.unibas.ch/api/iiif/11b4ca60-6bac-11eb-a1e6-005056b34690/manifest
Depending on how you use Loris to serve content, you will need to enable CORS for the IIIF requests.
Related
when I delete the image from my graphql server and using uploader.upload.destroy(public_id), it deletes from media library of cloudinary (https://cloudinary.com/console/media_library/folders/%2F)
but image is still available If I access it via cloudinary endpoint (https://res.cloudinary.com/db9rcrnuw/image/upload/v1576054005/47122.png)
I want to destroy those endpoints as well when the image is deleted.
here, screen.basePath means public_Id of the image
const screen = await ctx.prisma
.deleteScreen({
id: args.screenId
})
.$fragment(fragment);
if (scrn.basePath.length === 5) {
console.log(scrn.basePath.length);
cloudinary.uploader.destroy(screen.basePath, function(error, result) {
console.log(result, error);
});
return screen;
}
The short answer is that this is caused by a combination of not using the 'invalidate' parameter in your destroy API call and a difference between which URL format (i.e. with a version number (v123456789), 'v1' or no version number) the resource is accessed using versus what format your account is configured to send for invalidation.
The first thing to do is ensure that all destroy API calls include the 'invalidate' parameter set to 'true' if you'd like CDN invalidation.
Regarding the URL formats;
The 'v1576054005' that is part of delivery URLs is a version number that is essentially the UNIX timestamp of the upload time of the asset. Its main purpose is to always return the latest image and avoid CDN caching (upload API responses return the URL with the latest upload version). A bit more information on this topic can be found in this article - https://support.cloudinary.com/hc/en-us/articles/202520912-What-are-image-versions.
Please note that there are three possible URL formats Cloudinary can send for invalidation at the CDN, and these are outlined here: https://support.cloudinary.com/hc/en-us/articles/360001208732-What-URL-conventions-are-invalidated
Invalidation requests are sent when you delete or overwrite an image using the Media Library UI, or when you use the SDK/API, and also provide the 'invalidate' parameter, set to 'true'.
By default, all accounts send invalidations for the default format of URL which the SDKs produces, which uses no version number for assets in the root of your account, and a 'v1' placeholder for assets in folders (option 1 from the URL above).
If you were accessing the image with the full version component then that isn't sent for invalidation by default and why you are likely getting a cached copy returned.
In your case, the URL that would've been sent for invalidation would be without a version component (as the resource is in the root folder) i.e.
https://res.cloudinary.com/db9rcrnuw/image/upload/47122.png
Depending on how you are building your URLs, i.e., if you're using the SDK helper methods, taking the URL from the url or secure_url fields of the Upload API response (which use the full version number), will determine the format and thus how your account should be configured to invalidate.
I suggest you to email Cloudinary support (support#cloudinary.com) and share a link to this thread as well as some details on how the URLs you're using are generated so that your account can be configured accordingly.
I'm having a pretty weird problem with CORS on a webapp I'm trying to make
I'm using Servlets (Tomcat8.0) for the backend. It's a school project, so I can't use a framework
A GET request to http://localhost:8080/FileBox/dashboard
returns a JSON payload( plain json, not jsonp,which I could use, but its the same domain). I'm using ajax to make the XHR, but it's being blocked by chrome as CORS
Should this be happening, since I'm making the XHR from the same domain(host+port)
'localhost:8080/FileBox/dashboard.jsp'
to
'localhost:8080/FileBox/dashboard'
Please, and thank you for the help!
You aren't making a request to http://localhost:8080/FileBox/dashboard. The error message says you are making a cross-origin request using an unsupported scheme and that http is a supported scheme.
Presumably you have made the two mistakes of:
Getting the URL wrong
You should be using a relative URL:
/FileBox/dashboard
but are trying to use an absolute URL:
http://localhost:8080/FileBox/dashboard
but have typed it wrong and are actually requesting
localhost:8080/FileBox/dashboard
Not loading the page over HTTP to start with
Possibly by double clicking the file in your system file manager, you have bypassed your HTTP server and are loading something like file:///c:/users/you/yourproject/index.html
Combined with the previous mistake, you end up trying to request file:///c:/users/you/yourproject/localhost:8080/FileBox/dashboard, with Ajax and get a security violation.
Solution
Fix the URL to be a proper relative URL
Point your browser at http://localhost:8080 instead of double clicking files in your file manager
I'm having issues with using $http on ie8. The request does not reach the server, until I hit a refresh. Coming back to the same link still has the same problem until I hit refresh again.
The weird thing is if the web server is on LAN and the request is made to a server in LAN, it works fine. But if the webserver is hosted remotely, it does not work!
Here is the code:
Index.html
{{test}}
Controller
app.controller(
"TestController",
function( $scope, $http) {
var url = '/test/get_data';
$http.get(url).success(function(data) {
$scope.test = data;
});
}
);
I got this error: TypeError: Object doesn't support this property or methodundefined
I prepared a JSFiddle earlier but JSFiddle is broken in ie8 so I don't provide it here.
Unfortunately I don't have a remote server that I can share with you.
Edit
Previously I used an external url which gave me 'Access Denied' error in ie because of Same Origin Policy as mentioned by one answer below. But this was not my original problem. I still have the issue above when request is from the same origin
This is a cross domain request, which is not allowed in ajax because of Same Origin Policy.
There are two solutions for this
1. JSONP: It is a cross browser way to handle cross domain ajax requests using javascript callback mechanism
2. CORS: It is a HTML5 standard, it is implemented by most of the modern browsers except IE
Mongodb lab is not supporting jsonp since it has support for CORS, that is why your request is failing in IE and works in Chrome and other browsers.
As per this post they do not have any plan to support jsonp, so I don't thick there is a way to make this work in IE.
So I found the fix... Hope this helps anyone out there that experience this problem
Angular script needs to be loaded after jQuery. I didn't have this because Yii framework that I use autoloads jQuery and the angular was not included after the jQuery.
All the controller functions need to be at the end of body section (just before the closing )
Updating to angular 1.0.5 seems to fix the problem. The problem occurred in 1.0.4 with all the above tricks. I think is related to fix 791804bd
I use socket. IO to do a chat application, the client is 0.8.4 and running normally. But when I put the socket. 0.9.4 IO upgrade to find the cross domain problem, other documents did not change, the following is wrong content:
XMLHttpRequest cannot load http://localhost:8000/socket.io/1/? T = 1333528698474. http://mydomain.com Origin is not allowed by Access-Control-Allow-Origin.
Some people have the same problem? Or who know solution? Thank humbly!
I just got mine working by using http:// in my browser address bar instead of file://
This was my issue: https://github.com/LearnBoost/socket.io/issues/776
Set the Access-Control-Allow-Origin header to your URL in the response.
NodeJS sample using setHeader:
res.setHeader('Access-Control-Allow-Origin','http://mydomain.com');
// or
res.setHeader('Access-Control-Allow-Origin','*');
I am trying to optimize the performance of a Wicket 1.5.3 application.
I'm trying to get the caching configuration up and running. I've already reviewed "migration to 1.5" papers, the migration guide and samples. I've also ensured that there is a default caching strategy available, and tried to set a custom one.
getResourceSettings().setCachingStrategy(strat);
The app has CSS and JS in a Base-Frame.html header as link and script, and it has a lot of images. I'm currently using something like this:
Image img = new Image("logoutImg") {
protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
tag.put("src", baseUrl + "/images/logout.png");
}
};
With that, the HTTP header output is always:
Pragma No-cache
Cache-Control no-cache
for all resources and pages.
I've now implemented some servlet filters, which is a rather brutish method that avoids all previously set Wicket headers.
Could anyone provide a running working example, or some tips for getting this up and running? In particular, something using FilenameWithVersionResourceCachingStrategy would be really helpful, since that seems to be a good solution.
I guess you have to use Wicket's CachingImage class allowing you to set the headers accordingly to the browser