Okay that title might sound confusing but it's hard to describe in a title.
Basically, when you display an image online you typically reference it by URL as the image must be hosted somewhere. So for example this image url is:
https://www.gettyimages.ie/gi-resources/images/Homepage/Hero/UK/CMS_Creative_164657191_Kingfisher.jpg
So what I assume is happening is the link tells the webpage where to find the data and then the hosting server replies with the image.
My question is
If a web page can interpret a link with information such as
www.example.com/__?id=01&user=ExampleName&email=exampleEmail
and use that information (id, user, and email) to then generate an image could it return the data without actually hosting the image? As in it's just receiving a request and replying?
The goal of this is to have a page with an image that is a QR code generated by an external webapp.
Yes.
Implementation details would of course differ depending on the chosen server side language, but in the end you're going to send a response which would contain the generated image data (in your case the QR code) and the appropriate headers in order for the browser (or requester of the resource) to properly interpret the response.
Example of what you're asking for would be placeholder.com where it responds with an image depending on certain parameters you provide in the URL.
You can also check for example the requests being sent on https://www.qr-code-generator.com (and probably also other QR generator sites) and see that the codes there are generated similarly to your idea.
Related
I have a small web app which would be cool to post on a QR code as it works offline. However it appears that data URLs don't work an a QR code. Does anyone know a workaround for this? I would like to have a QR code that delivers HTML to the user's browser with no network connection.
QR codes just contain text. A data URL is just text. There is no problem putting one in a QR code.
Assuming the data URL is valid, the problem likely springs from the particular software you are using to decode it failing to recognise the URL scheme.
There isn't anything you can do about that beyond using other software or copy/pasting the whole thing into a web browser.
It depends on the file size. If your data url is less then 255 characters, yes. Try minifying it and using link shorteners for resources. You just need a link shortener that supports 301 redirects. Here's an example. The content is a data url for a plain-text file with the content "demo". Here's the data url. data:text/plain;charset=utf-8;base64,ZGVtbw== To test it, scan it with a phone, select the notification, copy the content, and paste it in Safari.
Let's say that we have two pages:
https://www.example.com/first/firstpage.html
https://www.example.com/second/secondpage.html
that both load the resource https://www.example.com/resource.js
If I want the server that serves resource.js to be able to serve a different version of resource.js depending on which page the request is coming from, is there a reliable header upon which the full URL of the requesting page can be determined (or maybe there is some other way to determine this)?
I know that there is an Origin header, but from my understanding this just represents the domain (and any subdomains) without the full URL and query string. Is there any way for the server to know the full URL and query string that the request for the resource is coming from?
If this isn't possible, I know it would be easy to include that info in the JS script tag as follows:
<script src="/resource.js?origin=/first/firstpage.html"></script>
But I don't want to have to modify the script tag for each page. Is there some other way to have the page automatically include it's own URL in the query string of the resource request (without having to dynamically load the resource using my own JS script - HTML only please!), or just any unique identifier so that the script tag doesn't have to be modified individually on each page?
There's the Referer header that you can use.
Make sure that your response uses Vary: Referer. Otherwise, browsers are going to cache this resource as if the referring page URL didn't matter.
I'd plead of you not to do this at all though. You're going to create a rabbit hole of problems, as not all browsers or proxy servers are well behaved. Some are going to aggressively cache this anyway, no matter what you do with the Vary header.
I know you can share messages with and this is working on android and ios now:
Share with whatsapp
However I'd like to share an image trough a button on my website like someone would share an image from his phone (gallery). Is this anyhow possible?
One solution that comes to mind is uploading a photo to your server via AJAX, returning the link to the uploaded photo and then sending a message with the link to your photo using the method you described in your question. This is not quite the same as sending an image directly using Whatsapp since the recipient would only receive a link, but I doubt there will ever be a way to send an image to another application from your gallery using a webpage since that would raise some serious concerns.
Roughly, the process would like this (keep in mind that this will require some testing to get right and find a solution that works well on all platforms or at least most of them):
Create an image upload on your website. Simply having <input type="file" accept="image/*"> on your page should, on most platforms, allow you to create a button which will open a dialog to select an image from your phone's gallery when clicked. You can find a full example here or use a library such as Plupload which contains many upload methods, including HTML5 which is what you need.
Create a simple server-side upload. This depends on your language and platform, but all you need to do is store the image somewhere and return a link to it in response. If you don't want to store these images on your server, you could forward it to Imgur API and upload there.
Redirect the user to the whatsapp:// link that contains the image link.
window.location = 'whatsapp://send?text='+encodeURIComponent(imageURL);
This is the point where you need to do some testing on different platforms, though. You might not be able to redirect to a whatsapp:// link this way (since it seems like a security concern), so you may need to trick it (this is a bad idea, but I'm including it for the sake of completeness; the data-action part is from this answer):
var fakeLink = document.createElement('a');
fakeLink.setAttribute('href', 'whatsapp://send?text='+encodeURIComponent(imageURL));
fakeLink.setAttribute('data-action', 'share/whatsapp/share');
fakeLink.click();
In the end, if neither of these work, your best bet is creating a link once the upload is complete for the user to "confirm" sending which actually contains the above whatsapp:// link in the href field.
There are many factors to test and some that are implementation specific so I had to keep it vague without much code - if you come across anything else when implementing this, please mention it in the comments.
Is there any way at all to get the meta information about a picture from a link without download the picture it self?
Like i have this url to a picture http://www.abc.com/picture.jpeg, i want to get the meta information such as the dimensions of the picture with out actually downloading the picture it self.
Of course I want to do this by writing a program, because there is large amount of pictures to go through.
I doubt you can get information about an image without downloading it. For example, when you visit a website and it has an image on it, the browser only knows the dimensions of the image after it has downloaded it. This is especially true if you want more advanced metadata such as time picture taken, iso, exposure, etc. The URL carries no information except if you can get some information from the parameters. Ex: http://www.abc.com/picture.jpeg?x=100
Sorry :/.
You might maybe want to look into downloading a thumbnail of the image, or maybe there is a way to not download the image pixel data but only the EXIF metadata which would cut down on download time/costs but still get you that metadata you want. I have no expertise in that subject though.
If all you have is a URL, than all you have is a URL. There's no magic incantation that will extract more data than there is from it. I.e.: No, you'll have to download the image.
If you have control over the server serving the image, you could make an HTTP HEAD request, have the server evaluate the image and output meta information about the image in the HTTP header, essentially creating a custom protocol for this purpose. That's a lot of ifs though and really depends on what you want to do.
We are building a site that allows users to collect and store their favorite products from all over the Internet to one spot. We have an algorithm that filters out and finds the correct image by reading the source code. 80% of the sites work correctly but 2 large companies are blocking redirecting us from a product page to their homepage.
For example this product http://www.gap.com/browse/product.do?pid=741123&kwid=1&sem=false&sdReferer=http://www.gap.com/products/graphic-ts-toddler-boy-clothing-C35792.jsp# picks up the header for gap.com main page and not for the product at hand.
How do we get around this redirect and allows our algorithm to collect the correct image by reading the correct source code?
First, you might ask a lawyer to study the terms of service of your target web sites, and make sure that you won't run into legal problems.
On the technical side, set the Referer [sic] header when requesting the image. The referrer for an image should be the page in which it is embedded. The server may check that to ensure that the image is being requested to satisfy a page render by a browser, rather than a image-harvesting screen scraper.
After a bit of testing with the image in question, it doesn't look the Referer header is required. Perhaps it is simply rejecting an unfamiliar user-agent, or is keying off some other oddity in the request, like a missing Accept header, etc.
I'd imagine you need to change your scraper's user agent string to something that looks like a normal browser (you're probably sending a string like curl or wget by default).
There's a good chance, though, that if you're sending enough traffic their way they'll eventually notice and shut you down in a harder-to-circumvent manner.