Getting the list of MediaItems can be done through Google Photos API as well as getting the MediaItem metadata as well as the media item itself.
What if the picture was modified online (e.g. brightness/contrast), then saved?
The MediaItem does not contain something like a hash-code.
How to detect if the photo has been modified?
Does Google Photos API support this use case and how?
There is currently no ability to see if a file was changed in the Google Photos api.
There is however a feature request for this currently Provide Modified Date in metadata which might be along what you are looking for.
As suggested in a comment you could probably do this yourself using MD5 but its not going to help you if you want the api to tell you if theres been a change your going to have to test the md5
Even though DalmTo's answer is true, there is a workaround to this issue.
The HTTP Content-Length header is set with every response when downloading a media item, so one can "probe" the actual media item and stop downloading.
The Content-Length value is the value the item would have as file size after downloading. Assuming changes don't end up having the same file size, this value will be different if a file has been changed (cropped, rotated, etc...).
Related
I created Candy Machine and I noticed that some NFT images are not displayed neither on wallet or solscan. Metadata and images were uploaded and pinned on Pinata using Candy Machine upload command which finished successfully.
Here is an example of broken NFT.The metadata URI is pointed to: and image is pointing to. I looked at metadata several times and could not find what is the issue and why is this happening to some of the NFTs (here is the example of valid NFT that does not have this problem).
Questions:
What is the problem with metadata which is causing image not to be displayed?
What is the best way to fix this? Metadata are mutable and I am planing to use metaboss to update URI of metadata file. Is this correct way of fixing this problem?
If you look at the URI metadata on solscan here
https://solscan.io/token/4ToXb3aD5YLpXqyZhcdp5ynpbXXFFjKjsaw1x94CTd7A#metadata
and swap to the URI version of the metadata for some reason it's returning an object keypair value out of every single character in the JSON for some reason, extremely weird. I'd highly recommended reuploading this JSON metadata file and then updating the metadata URI in the NFT to make the changes.
Metaboss is a great tool as you have researched that can do this for you.
Upload new Metadata json to ipfs or arweave.
Use Metaboss to udpate the NFT's metadata URI.
Hopefully this fixes your issue.
While not a conclusive answer as to "why" this happened, I don't really know the why. This is my first time in all the NFT's that I've seen that have behaved this way upon an upload and displaying the metadata.
If that doesn't fix your issue please stop by the Metaplex Discord server and chat with us there. :)
Edit: After further inspection it turns out your JSON file is of an invalid structure for this particular NFT so will definately need replacing.
Tony Boyle has a great point with updating your json.
Your problem gets visible when you run the json through a JSON validator.
It will show that you have too many } in there. Therefore parsing the JSON fails in solscan, phantom etc.
What you have to do is
Modify the metadata to be a valid JSON file
upload it again
update the NFT uri e.g. with metaboss (if you need to update multiple NFTs) or if its just one / a few https://sol-tools.tonyboyle.io/update-nft
I use the Windows Azure Blob Storage to keep files there.
To download files i create urls with Shared Access Signature.
It works fine, but there is one problem.
Some files (blobs) have the header "Content-Type" set during upload and other no.
if a file has no Content-Type than on request to Azure the response will have the header Content-Type: application/octet-stream . This is exactly what i need, because in such case a browser will show "Download dialog" for a user.
But for files where this header was set on upload, it is returned and sometimes it makes a problem. For example, Content-Type: images/jpeg makes a browser to show this image, but not download it (does not show Download dialog)
So, my question is
is there a way on download with presigned url from WIndows Azure to force to use some specific response header?
I want it behave like there is no Content-Type saved for a file, even if it is saved
So, after some time browsing i finally found the documentation about it.
There are references.
https://nxt.engineering/en/blog/sas_token/
https://learn.microsoft.com/en-us/rest/api/storageservices/service-sas-examples
https://learn.microsoft.com/en-us/rest/api/storageservices/create-service-sas
For me it was needed to up the version of the API (i used the 2012 API version).
Also one useful note. It is very sensetive to a date format. The expiraton time must be in the format like "2021-11-16T04:25:00Z" .
I have added 2 new arguments
'rscd=file;%20attachment&rsct=binary&'.
and both of the must be in the signature string to sign on their correct places
So, my question is is there a way on download with presigned url from
WIndows Azure to force to use some specific response header? I want it
behave like there is no Content-Type saved for a file, even if it is
saved
Yes, you can override Content-Disposition response header in your SAS Token and the blob will be always downloaded regardless of it’s content type.
You can override this header to a value like attachment; filename=yourdesiredfilename and the blob will always be downloaded with yourdesiredfilename name.
The Google Drive API v2 to v3 migration guide says:
The exportLinks field has been removed from files. To export Google Documents, use the files.export method instead.
I don't want to export (download) the file right away. "files.export" will actually download the file. I want a link to download the file, later. This was possible in v2 by means of the exportLinks.
How can I in v3 accomplish the same? If it is not possible, why was this useful feature removed?
Besides, (similar problem to above) downloadUrl was also removed, and the suggested alternative ("files.get with ?alt=media") downloads the file instead of providing a download link. This means there is no way in v3 to get a public short lived URL for a file?
EDIT:
there is no way in v3 to get a public short lived URL for a file?
For regular files, apparently yes.
This seems to work fine (a public short lived link to the file with its right name and contents):
https://www.googleapis.com/drive/v3/files/ID?alt=media&access_token=TOKEN
For google apps files, no (not even private, as v2 exportLinks used to be).
https://www.googleapis.com/drive/v3/files/ID/exportmimeType=TYPEv&access_token=TOKEN
Similar to regular files, this URL is a short lived link to the file contents, but lacking of its right name.
BTW, I see the API is not behaving consistently: /drive/v3/files/FILEID delivers the right file name, but /drive/v3/files/FILEID/export does not.
I think the API itself should be setting the right Content-Disposition, as it is apparently doing when issuing a /drive/v3/files/FILEID call.
This file naming problem invalidates the workaround to the lack of ExportLinks in v3.
The v2 ExportLinks allowed me to link a file (which is not the same as getting its content right away). Anyone logged in and with the proper permissions was able to access it, and the link didn't needed any access_token, and it wasn't short lived. It was good and useful.
Building a link with a raw API call like /drive/v3/files/FILEID/export (with mandatory access_token) would be an close enough workaround (it is temporary and public, not the same as it was, anyway). However, the naming problem invalidates it.
In v2, regular files have a WebContentLink and google apps files have exportLinks. In v3 exportLinks are gone, and I don't see any suitable alternative to them.
Once you query for your file by id you can use the function getWebContentLink() to get the download link of the file (eg. $file->getWebContentLink() ).
I think you're placing too much emphasis on the word "method".
There is still a link to export a file, it's https://www.googleapis.com/drive/v3/files/fileIdxxxxx/export&mimeType=xxxxx/xxxxx. Make sure you URL encode the mime type.
Eg
https://www.googleapis.com/drive/v3/files/1fGBQ81haNU_nEiC5GITZD3bxT0ppL2LHg-C0ubD4Q_s/export?mimeType=text/csv&access_token=ya29.Gmo0BMvO-pVEPKsiD9j4D-NZVGE91MChRvwOcBSg3cTHt5uAClf-jFxcovQScbO2QQhwHS95eSGW1eQQcK5G1UQ6oI4BFEJJkntEBkgriZ14GbHuvpDL7LT2pKA--WiPuNoDDIuZMm5lWtlr
These links form part of the API, so the expectation is that you've written a client that sends authenticated requests, and deals with the response data. This explains why, if you simply paste the link into a browser without an access_token, it will fail. It also explains why the filename is export, ie. it isn't intended that your client would ever use a filename, but rather it should receive the data as a stream. This SO answer discusses the situation in more detail How to set name of file downloaded from browser?
I have created a Google App Engine project where it's possible to upload photos. Uploading part is working fine and all the photos are uploaded in proper size. But when I try getting images.get_serving_url , it returns me serving_url appended with lh3.googleusercontent.com but according to GoogleAppEngine documentation it must return serving_url something like lh3.gghpt.com . Also, the problem which comes is that the photos on that serving_url is 4-6 times smaller than the uploaded ones and when I view in the GoogleAppEngine console, all those photos have same size as the uploaded ones. I don't know why GoogleAppEngine is not returning the actual sized images.
Try specifying size=0 in the images.get_serving_url method call.
eg. images.get_serving_url(blob_key, size=0)
I'm new and just developing on J2EE.
I am modifying an existing application (an OpenSource project).
I need to save an image on a client sent by the server, but I do not know how.
This activity must be done in a transparent manner without affecting the existing operation of the application.
From the tests done I get this error:
java.lang.IllegalStateException: getWriter () has Already Been Called for this response.
How should carry out this task, according to your own opinion?
How do I save on the client, locally, the image?
Update:
Thanks for the answers.
My problem is that:
the image is generated on the server, but not for direct client request (there is no link to click on web page), the picture is composed using other services on the Internet.
reconstruct the image on the server.
This image must be sent to the client to be saved locally.
so I'd like it to appear a window where you assign the destination image
plus I'd like the rest of the application were not affected by this activity.
The application is yet on production.
Thank you very much for your response.
From the tests done I get this error: java.lang.IllegalStateException: getWriter () has Already Been Called for this response.
In other words, you were trying to mix the binary data of the image with the character data of the HTML output, or you were trying to do this in a JSP instead of a Servlet. This is indeed not going to work. You need to send either the image or the HTML page exclusively in response to fully separate requests.
In your JSP/HTML page just have a link to the image, like so:
click to download image
Then, in a servlet listening on an url-pattern of /imageservlet/*, you just get the image as InputStream from some datasource (e.g. from local disk file system as FileInputStream) and then write it to the OutputStream of the response the usual Java IO way.
You only need to set at least the Content-Disposition response header to attachment to make sure that the client get a Save As popup dialogue, else it will be displayed straight in the browser. Setting the Content-Type and Content-Length are also important so that the browser knows what the server is sending and can predict how long the download may take.
response.setHeader("Content-Type", getServletContext().getMimeType(file.getName()));
response.setHeader("Content-Length", String.valueOf(file.length()));
response.setHeader("Content-Disposition", "attachment;filename=\"" + file.getName() + "\"");
You can find complete basic servlet example in this article.
Note: you cannot control where the client would save the image, this would be a security hole. This way websites would be able to write malicious files on client's disk unaskingly.
Update: as per your update, there are two options:
You need to let the client itself fire two HTTP requests (I've answered this in your subsequent question)
Create a client side application which does all the task directly at the client side and then embed this in your webpage, for example a Java Applet. With an applet you have full control over the client environment. You can execute almost all Java code you'd like to execute and you can write files to disk directly without asking client for the location to save. You only need to sign the applet by a 3rd party company or the client needs to confirm a security warning before running.
Its up to the browser how all types of output are handled. Web pages are given a content type of html which the browser understands and ends up rendering ass a page that we can see. Images are given content type of image/jpeg etc which are rendered as images when in a page etc. To force a download prompt one needs to use a content type of a binary file rather than that of an image so the browser forces the download rather than shows the image. To ensure this use something like "application/octetstream"... i cant recall exactly but its easy to google for.