The picture of Aliyun oss and the original picture protection option is turned on, which causes the lightbox to be incorrectly loaded in the article

[GHNature]

When I refer to the image from oss in the article, it can be loaded normally, but when I turn on the original image protection switch, the image can only be accessed through a specific url, that is, by adding a suffix to the original url, but this causes the lightbox can't pop up, and can't get metadata. I found in a plugin called 'Meow Lightbox' that exif can be obtained and loaded normally, but I prefer to use this plugin. Can you solve the following when you have time? please. this is my picture url https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark

[arnowelzel]

Parameters like ?x-oss-process=style/watermark will be removed before the image is processed because usally the plugin is used to work with local files and not URLs.

I added a workaround to keep parameters for images loaded from "external" URLs - which means the URL in the image is not the same as the website where it used. So at least the image can be used with that URL. This will be included with the next update.

However the image referred by the URL https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark does not contain any EXIF data. I don't know, how Meow Lightbox is able to obtain the data. Did you configure something for Meow Lightbox to get the a local filename as well so it can extract the data from the local file?

[GHNature]

Parameters like ?x-oss-process=style/watermark will be removed before the image is processed because usally the plugin is used to work with local files and not URLs.

I added a workaround to keep parameters for images loaded from "external" URLs - which means the URL in the image is not the same as the website where it used. So at least the image can be used with that URL. This will be included with the next update.

However the image referred by the URL https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark does not contain any EXIF data. I don't know, how Meow Lightbox is able to obtain the data. Did you configure something for Meow Lightbox to get the a local filename as well so it can extract the data from the local file?

Hello, there is nothing special about the setting of Meow Lightbox, this is the screenshot 'https://oss.ihooai.com/img/1663783192722.jpg?x-oss-process=style/watermark', I am curious why it can read Take the image-protected exif. After many times of uploading pictures by controlling variables, I found that only when wordpress uploads pictures to oss storage, I upload them directly to oss through plugins, and they will not be retained on the website server. When uploading pictures in the article or selecting pictures stored in the remote oss from the wordpress media library, only in this way can the plugin Meow Lightbox read the picture exif information. Finally, thank you very much for updating the url processing rules in time, which solved the problem I debugged for a long time.

[GHNature]

Parameters like ?x-oss-process=style/watermark will be removed before the image is processed because usally the plugin is used to work with local files and not URLs.

I added a workaround to keep parameters for images loaded from "external" URLs - which means the URL in the image is not the same as the website where it used. So at least the image can be used with that URL. This will be included with the next update.

However the image referred by the URL https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark does not contain any EXIF data. I don't know, how Meow Lightbox is able to obtain the data. Did you configure something for Meow Lightbox to get the a local filename as well so it can extract the data from the local file?

Hi, I have tested again with Meow Lightbox and Lightbox with PhotoSwipe plugins. At the same time I have a plugin for Oss Upload, it has an option to 'use oss as wordpress media repository', when I open it, the images uploaded from wordpress will not be saved in the website server, but directly uploaded to the oss server, The corresponding image resources in oss are displayed in the media library. When I close it, the front part of the image link in the media library will become ${domain name of this site}/wp-content/uploads/, which is the directory of this site.

1. In the previous version of Lightbox with PhotoSwipe, if I turned on the 'image protection' option on the oss server, the exif could not be loaded, and this plugin could not pop up normally. When I turned off the 'image protection', the exif could be read normally. , clicking on the picture can pop up the window normally, although the picture link has processing parameters. In this version, no matter whether the oss 'image protection' is turned on or off, the lightbox can be popped up normally, but the exif cannot be read. Only when I turn off the 'use oss as a media repository' option of the plugin Oss Upload, The picture is uploaded to the website server directory, which is a link such as ${domain name of this site}/wp-content/uploads/, and the exif can be read by inserting the picture. 2.Meow Lightbox can read exif only for pictures uploaded via Wordpress, no matter if 'Picture Protection' option is turned on, or if Oss Upload is enabled. This is my picture link https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg, 'picture protection' is currently turned off, and the picture processing parameters are https://oss.ihooai.com/2022 /09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark. Can it be processed in this way, lightbox directly loads the url of the image without removing the processing parameters, and try to read from the url after removing the processing parameters exif. thanks for reading.

[arnowelzel]

Since the protected image does not contain any EXIF data at all, it must be read when uploading it and not later.

However to find out what is going on exactly I would have to have a look to your server backend. We can arrange a session using Jitsi Meet and screen sharing so we can have a look together. If this is ok for you, just contact me via e-mail at github@arnowelzel.de.

[GHNature]

Since the protected image does not contain any EXIF data at all, it must be read when uploading it and not later.

However to find out what is going on exactly I would have to have a look to your server backend. We can arrange a session using Jitsi Meet and screen sharing so we can have a look together. If this is ok for you, just contact me via e-mail at github@arnowelzel.de.

Hello, Arno, I modified the judgment of whether it is a local file in line 415 of LightboxPhotoSwipe.php in my website, and removed the parameter splicing when reading exif in line 450. I don't know if this is reasonable, but after testing, the lightbox works regardless of whether I turn on the original image protection in oss. When I turn off the original image protection, it can display the exif information, otherwise it does not display the exif. Here is my modified screenshot "https://oss.ihooai.com/img/202209231328120.png?x-oss-process=style/watermark"

[arnowelzel]

First of all it should work without your modifictions. And again the image with protection at https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark does not contain EXIF data.

See for yourself with https://jimpl.com

And in contrast compare that with one of my sample images like https://wordpress-demo.arnowelzel.de/wp-content/uploads/2019/09/IMG_6972.jpg

So if Meow Gallery does show EXIF data it does not take it from that URL! It must read that data during the upload. I can not solve this sorry.

[GHNature]

Hello, what I mean is, use the link after removing the parameters when reading the exif information, as in the previous version, and then I commented on the judgment of whether it is a local file, so that when I turn off the original image protection option, It can read exif, this is the picture link "https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg", you can download it. I don't understand php syntax very well, so I tried to change "https://oss.ihooai.com/img/202209231328120.png?x-oss-process=style/watermark", I don't know if it's reasonable, but it does work for me It takes effect locally. If you don't consider adding it to the new version, then I can put it locally. Thank you as well.

994802889 @.***

 

------------------ 原始邮件 ------------------ 发件人: "arnowelzel/lightbox-photoswipe" @.>; 发送时间: 2022年9月23日(星期五) 下午5:39 @.>; @.**@.>; 主题: Re: [arnowelzel/lightbox-photoswipe] The picture of Aliyun oss and the original picture protection option is turned on, which causes the lightbox to be incorrectly loaded in the article (Issue #93)

First of all it should work without your modifictions. And again the image with protection at https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark does not contain EXIF data.

See for yourself with https://jimpl.com

And in contrast compare that with one of my sample images like https://wordpress-demo.arnowelzel.de/wp-content/uploads/2019/09/IMG_6972.jpg

So if Meow Gallery does show EXIF data it does not take it from that URL! It must read that data during the upload. I can not solve this sorry.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[arnowelzel]

The URL https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg can not be loaded if image protection is enabled - at least the last time I tried that I got an error message "direct image linking is not allowed".

So even If I would add an option to remove parameters in the image URL before reading the EXIF data - that will not work if you enable image protection. Because the whole idea of the image protection is to only allow viewing the image with wartermark enabled and not using it without watermark.

[GHNature]

Yes, I understand what you mean, but the latest version cannot load the exif information of the image from the external url if it is not read from the local directory, regardless of whether it has image protection turned on. If I change it like this, it can read exif from the image loaded in the external url as in the previous version, and it can also pop up the lightbox after the image protection is turned on, but the previous version could not pop up. But I don't know if it's reasonable to change the code like this“https://oss.ihooai.com/img/202209231328120.png?x-oss-process=style/watermark”.

994802889 @.***

 

------------------ 原始邮件 ------------------ 发件人: "arnowelzel/lightbox-photoswipe" @.>; 发送时间: 2022年9月23日(星期五) 晚上6:03 @.>; @.**@.>; 主题: Re: [arnowelzel/lightbox-photoswipe] The picture of Aliyun oss and the original picture protection option is turned on, which causes the lightbox to be incorrectly loaded in the article (Issue #93)

The URL https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg can not be loaded if image protection is enabled - at least the last time I tried that I got an error message "direct image linking is not allowed".

So even If I would add an option to remove parameters in the image URL before reading the EXIF data - that will not work if you enable image protection. Because the whole idea of the image protection is to only allow viewing the image with wartermark enabled and not using it without watermark.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[arnowelzel]

You can add code here as well like this, there is no need to create screenshots:

original:

                        $exif = @exif_read_data( $file . $params, 'EXIF', true );

your version:

                        $exif = @exif_read_data( $file, 'EXIF', true );

However - the $params paramter must be there - it is part of the URL if the image is external. Just because your images also work without any parameters this does not mean that this is always the case.

I could add an option in the backend to ignore parameters in the image URL to get the EXIF data. However: if your images work without any parameter in the URL anyway, why do you add that in the first place? In that case people just can do the same, remove the parameters and just copy the original image without watermark. Especially since the parameter is ?x-oss-process=style/watermark it is obvious that this is used to add a watermark.

So both of these images work, the second is just without watermark - but if I can do that, anyone else can do this as well:

https://oss.ihooai.com/img/202209231328120.png?x-oss-process=style/watermark

https://oss.ihooai.com/img/202209231328120.png

But if the image is protected so it can not be viewed without that parameter, then this applies to my plugin as well - without getting the unprotected image there is no EXIF information available.

My recommendation: if you want to have a watermark in the images as a kind of copyright protection you should add that to the original image, so it does not need any parameters in the URL and the orignal image can not easily obtained by just removing the URL parameters.

[GHNature]

You can add code here as well like this, there is no need to create screenshots:

original:

                        $exif = @exif_read_data( $file . $params, 'EXIF', true );

your version:

                        $exif = @exif_read_data( $file, 'EXIF', true );

However - the $params paramter must be there - it is part of the URL if the image is external. Just because your images also work without any parameters this does not mean that this is always the case.

I could add an option in the backend to ignore parameters in the image URL to get the EXIF data. However: if your images work without any parameter in the URL anyway, why do you add that in the first place? In that case people just can do the same, remove the parameters and just copy the original image without watermark. Especially since the parameter is ?x-oss-process=style/watermark it is obvious that this is used to add a watermark.

So both of these images work, the second is just without watermark - but if I can do that, anyone else can do this as well:

https://oss.ihooai.com/img/202209231328120.png?x-oss-process=style/watermark

https://oss.ihooai.com/img/202209231328120.png

But if the image is protected so it can not be viewed without that parameter, then this applies to my plugin as well - without getting the unprotected image there is no EXIF information available.

My recommendation: if you want to have a watermark in the images as a kind of copyright protection you should add that to the original image, so it does not need any parameters in the URL and the orignal image can not easily obtained by just removing the URL parameters.

The '?x-oss-process=style/watermark' is an image processing parameter named by myself. It is a function of image compression, watermark, transparency, etc. provided by oss, and it can also be other characters. Of course, I can choose not to use the image processing function, then the url will not contain parameters, I can add a watermark to the photo in the early stage, compress it and upload it, or keep the metadata, but I may erase the location information in it. There is currently a problem that images inserted through external links cannot display metadata in the latest version, even if I uncheck Ignore external links in the plugin settings. I also changed one place in the code,

original:

if ($isLocal && false !== $imageSize && is_numeric($imageSize[0]) && is_numeric($imageSize[1]) && $imageSize[0] > 0 && $imageSize[1] > 0)

my version:

if (/*$isLocal && */false !== $imageSize && is_numeric($imageSize[0]) && is_numeric($imageSize[1]) && $imageSize[0] > 0 && $imageSize[1] > 0)

I don't know if you have tried to insert pictures of other sites through url in the article https://oss.ihooai.com/2022/09/bf1255abe041cc66c0ea4a3bee7eb55e.jpg, when I modified it and read it from the external url without parameters getting the image metadata and it can be displayed.

[arnowelzel]

Please check the latest version, the line already changed the way how $isLocal is used in the code.

And the problem is not "external links"! It is the fact, that ?x-oss-process=style/watermark will remove EXIF data. So if you use that parameter the EXIF data will not remain in the image! It's just visible here as "internal" links will ignore URL parameters since they are expected to be FILES and NOT LINKS!

I am reluctant to add an option to remove the parameters, as using a different URL without parameters just for reading EXIF is a very special use case which many people may not even understand. But I may add a filter for the next update which allows to remove the parameters from the URL for the EXIF data fetching.

[GHNature]

Please check the latest version, the line already changed the way how $isLocal is used in the code.

And the problem is not "external links"! It is the fact, that ?x-oss-process=style/watermark will remove EXIF data. So if you use that parameter the EXIF data will not remain in the image! It's just visible here as "internal" links will ignore URL parameters since they are expected to be FILES and NOT LINKS!

I am reluctant to add an option to remove the parameters, as using a different URL without parameters just for reading EXIF is a very special use case which many people may not even understand. But I may add a filter for the next update which allows to remove the parameters from the URL for the EXIF data fetching.

Great! I have tested it and it works fine. As for the external url with parameters cannot read exif, I can also manually comment the parameter splicing when exif is accessed in the local code. Parameter processing is just that the oss server further processes the uploaded image, and it requires that the original image protection must be accessed through parameters after it is turned on. In fact, if I want to display exif, I have to turn off the original image protection, erase the location information in the early stage, and give it a certain amount of compression before uploading it. Of course, as you said, it might be better for me if filters can be added in the next version without a big impact on the code logic. Thanks for your patience, Arno, it's a really nice plugin, so smooth and auto-hide buttons, nice design. Off topic, I don't know if you have considered a function like this, https://enviragallery.com/envira/envira-protection-demo/#!enviragallery488761-488792 Add a button to the lightbox to display thumbnails of all the images contained in the article, and I found that most plugins are used in Gallery. Or this is the case on the mobile app.

[arnowelzel]

Beware!

This image can be opened:

https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark

But this NOT:

https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg

The second URL will only create an error message:

So even if I add a filter to remove the parameter before loading the EXIF data - this would not work! Because the protected image can only be read WITH parameters, not without!

Or does the image protection allow reading images from your server without parameters as well?

[GHNature]

Beware!

This image can be opened:

https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark

But this NOT:

https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg

The second URL will only create an error message:

So even if I add a filter to remove the parameter before loading the EXIF data - this would not work! Because the protected image can only be read WITH parameters, not without!

Or does the image protection allow reading images from your server without parameters as well?

Sorry, I turned on image protection, now I have turned it off. After the image protection is turned on, the pictures in the oss server can only be accessed through parameters.

[arnowelzel]

Beware! This image can be opened: https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark But this NOT: https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg The second URL will only create an error message: So even if I add a filter to remove the parameter before loading the EXIF data - this would not work! Because the protected image can only be read WITH parameters, not without! Or does the image protection allow reading images from your server without parameters as well?

Sorry, I turned on image protection, now I have turned it off. After the image protection is turned on, the pictures in the oss server can only be accessed through parameters.

You don't have to be sorry - I just want to show you the problem:

When you turn on image protection it will NEVER be possible to get the EXIF data as omitting the parameters will not work!

Therefore I won't add a filter for this as it does not help anyway for protected images.

Edit: and also keep in mind that even if you turn off image protection to get the EXIF data once, the data will only be cached for 24 hours as transients and then need to be updated again.

[GHNature]

Beware! This image can be opened: https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark But this NOT: https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg The second URL will only create an error message: So even if I add a filter to remove the parameter before loading the EXIF data - this would not work! Because the protected image can only be read WITH parameters, not without! Or does the image protection allow reading images from your server without parameters as well?

Sorry, I turned on image protection, now I have turned it off. After the image protection is turned on, the pictures in the oss server can only be accessed through parameters.

You don't have to be sorry - I just want to show you the problem:

When you turn on image protection it will NEVER be possible to get the EXIF data as omitting the parameters will not work!

Therefore I won't add a filter for this as it does not help anyway for protected images.

Edit: and also keep in mind that even if you turn off image protection to get the EXIF data once, the data will only be cached for 24 hours as transients and then need to be updated again.

Even though I turn off image protection, when I insert the url with parameters, it can't show the exif, when I insert the url without the parameter, it can show the exif. In version xx.11, exif can be displayed in both cases. I mistakenly thought that the filter you said was to solve this problem. Yes, because there is a cache, I have newly inserted pictures to test.

https://oss.ihooai.com/img/202209261622120.jpg?x-oss-process=style/watermark https://oss.ihooai.com/img/202209261620806.jpg

[arnowelzel]

Even though I turn off image protection, when I insert the url with parameters, it can't show the exif, when I insert the url without the parameter, it can show the exif. In version xx.11, exif can be displayed in both cases. I mistakenly thought that the filter you said was to solve this problem. Yes, because there is a cache, I have newly inserted pictures to test.

https://oss.ihooai.com/img/202209261622120.jpg?x-oss-process=style/watermark https://oss.ihooai.com/img/202209261620806.jpg

Maybe there is a misunderstanding:

You WANT to have image protection enabled - and THEN EXIF data will NEVER be available, also without parameters!

And even if you temporary disable the protection to get the EXIF data and then enable it again, the data will disappear after 24 hours as then the cache becomes invalid and the EXIF data can not be retrieved again from the protected images.

That's why I recommened to add a copyright watermark on your own instead of using some external service for that. This way you can keep the EXIF data and don't have to deal with this issue.

[GHNature]

Even though I turn off image protection, when I insert the url with parameters, it can't show the exif, when I insert the url without the parameter, it can show the exif. In version xx.11, exif can be displayed in both cases. I mistakenly thought that the filter you said was to solve this problem. Yes, because there is a cache, I have newly inserted pictures to test.

https://oss.ihooai.com/img/202209261622120.jpg?x-oss-process=style/watermark https://oss.ihooai.com/img/202209261620806.jpg

Maybe there is a misunderstanding:

You WANT to have image protection enabled - and THEN EXIF data will NEVER be available, also without parameters!

And even if you temporary disable the protection to get the EXIF data and then enable it again, the data will disappear after 24 hours as then the cache becomes invalid and the EXIF data can not be retrieved again from the protected images.

That's why I recommened to add a copyright watermark on your own instead of using some external service for that. This way you can keep the EXIF data and don't have to deal with this issue.

So the program currently only reads exif from the given url, and does not remove the parameters to read, right? Even if I never turn on image protection, in order to be able to display the exif, I have to add a watermark and upload it myself instead of processing it through parameters.

[arnowelzel]

So the program currently only reads exif from the given url, and does not remove the parameters to read, right? Even if I never turn on image protection, in order to be able to display the exif, I have to add a watermark and upload it myself instead of processing it through parameters.

It does not matter where the EXIF is read from!

If you turn on image protection EXIF can not be read at all! It does not matter if with our without parameters!

[GHNature]

So the program currently only reads exif from the given url, and does not remove the parameters to read, right? Even if I never turn on image protection, in order to be able to display the exif, I have to add a watermark and upload it myself instead of processing it through parameters.

It does not matter where the EXIF is read from!

If you turn on image protection EXIF can not be read at all! It does not matter if with our without parameters!

This is the case, image protection is not related to parameter processing, which can add watermarks to pictures, set quality and so on. If image protection is turned on, it can only be accessed via parameters. Then suppose I never turn on image protection. The current situation is that although I do not turn on image protection, I want to add watermarks to images through parameter processing and set a certain compression quality. After testing, I found that URLs with parameters cannot show exif.

So for exif, I only have to prepare the image for uploading myself and turn off the parameter processing function?

[arnowelzel]

Yes, I understand the situation. But this is a very special use case which likely no one else will ever have.

Adding watermarks should always be done in the original image - because if you disable the protection just to be able to get the EXIF data without parameters the whole idea makes no sense at all. If you do that, people can easily just copy the original images by removing the parameter from the URL!

That's why I recommended to add copyright watermarks on your own and not to use any external service for that.

[GHNature]

Yes, I understand the situation. But this is a very special use case which likely no one else will ever have.

Adding watermarks should always be done in the original image - because if you disable the protection just to be able to get the EXIF data without parameters the whole idea makes no sense at all. If you do that, people can easily just copy the original images by removing the parameter from the URL!

That's why I recommended to add copyright watermarks on your own and not to use any external service for that.

OK, I get it. Actually I'm still thinking of disabling image downloads through other plugins. But for professionals, they can still remove the parameters to get the original image. I don't understand how those apps can both display exif and protect images, maybe not the same as browser security.

[arnowelzel]

You can not really disable image downloads at all. Even if you disable the context menu for the mouse (very bad idea as there are completely legal use cases why people might want to use the context menu of their browser), one can still use the browser web developer console to get the source code to see the image URL. Also screenshots are also always possible.

That's the reason for copyright watermarks - there are visible watermarks but also watermarks which are not visible but which can be detected as a kind of cryptographic signature, so it is easy to identify illegal copies used somewhere else on public websites.

See more about all this here:

https://graphpaperpress.com/blog/protect-website-image-stealing/

https://www.copyrighted.com/blog/image-protection-online

[GHNature]

You can not really disable image downloads at all. Even if you disable the context menu for the mouse (very bad idea as there are completely legal use cases why people might want to use the context menu of their browser), one can still use the browser web developer console to get the source code to see the image URL. Also screenshots are also always possible.

That's the reason for copyright watermarks - there are visible watermarks but also watermarks which are not visible but which can be detected as a kind of cryptographic signature, so it is easy to identify illegal copies used somewhere else on public websites.

See more about all this here:

https://graphpaperpress.com/blog/protect-website-image-stealing/

https://www.copyrighted.com/blog/image-protection-online

Ok，thank you. I'll read it for more.

[GHNature]

The '?x-oss-process=style/watermark' is an image processing parameter named by myself. It is a function of image compression, watermark, transparency, etc. provided by oss, and it can also be other characters. Of course, I can choose not to use the image processing function, then the url will not contain parameters, I can add a watermark to the photo in the early stage, compress it and upload it, or keep the metadata, but I may erase the location information in it. There is currently a problem that images inserted through external links cannot display metadata in the latest version, even if I uncheck Ignore external links in the plugin settings. I also changed one place in the code, original:

                        if ($isLocal && false !== $imageSize && is_numeric($imageSize[0]) && is_numeric($imageSize[1]) && $imageSize[0] > 0 && $imageSize[1] > 0) my version:

                         if (/$isLocal && /false !== $imageSize && is_numeric($imageSize[0]) && is_numeric($imageSize[1]) && $imageSize[0] > 0 && $imageSize[1] > 0) I don't know if you have tried to insert pictures of other sites through url in the article https://oss.ihooai.com/2022/09/bf1255abe041cc66c0ea4a3bee7eb55e.jpg, when I modified it and read it from the external url without parameters getting the image metadata and it can be displayed.

994802889 @.***

 

------------------ 原始邮件 ------------------ 发件人: "arnowelzel/lightbox-photoswipe" @.>; 发送时间: 2022年9月23日(星期五) 晚上7:25 @.>; @.**@.>; 主题: Re: [arnowelzel/lightbox-photoswipe] The picture of Aliyun oss and the original picture protection option is turned on, which causes the lightbox to be incorrectly loaded in the article (Issue #93)

You can add code here as well like this, there is no need to create screenshots:

original: $exif = @exif_read_data( $file . $params, 'EXIF', true );
your version: $exif = @exif_read_data( $file, 'EXIF', true );
However - the $params paramter must be there - it is part of the URL if the image is external. Just because your images also work without any parameters this does not mean that this is always the case.

I could add an option in the backend to ignore parameters in the image URL to get the EXIF data. However: if your images work without any parameter in the URL anyway, why do you add that in the first place? In that case people just can do the same, remove the parameters and just copy the original image without watermark. Especially since the parameter is ?x-oss-process=style/watermark it is obvious that this is used to add a watermark.

So both of these images work, the second is just without watermark - but if can do that, anyone else can do this as well:

https://oss.ihooai.com/img/202209231328120.png?x-oss-process=style/watermark

https://oss.ihooai.com/img/202209231328120.png

But if the image is protected so it can not be viewed without that parameter, then this applies to my plugin as well - without getting the unprotected image there is no EXIF information available.

My recommendation: if you want to have a watermark in the images as a kind of copyright protection you should add that to the original image, so it does not need any parameters in the URL and the orignal image can not easily obtained by just removing the URL parameters.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[GHNature]

The '?x-oss-process=style/watermark' is an image processing parameter named by myself. It is a function of image compression, watermark, transparency, etc. provided by oss, and it can also be other characters. Of course, I can choose not to use the image processing function, then the url will not contain parameters, I can add a watermark to the photo in the early stage, compress it and upload it, or keep the metadata, but I may erase the location information in it. There is currently a problem that images inserted through external links cannot display metadata in the latest version, even if I uncheck Ignore external links in the plugin settings. I also changed one place in the code, original:

                        if ($isLocal && false !== $imageSize && is_numeric($imageSize[0]) && is_numeric($imageSize[1]) && $imageSize[0] > 0 && $imageSize[1] > 0) my version:

                         if (/$isLocal && /false !== $imageSize && is_numeric($imageSize[0]) && is_numeric($imageSize[1]) && $imageSize[0] > 0 && $imageSize[1] > 0)

I don't know if you have tried to insert pictures of other sites through url in the article https://oss.ihooai.com/2022/09/bf1255abe041cc66c0ea4a3bee7eb55e.jpg, when I modified it and read it from the external url without parameters getting the image metadata and it can be displayed.

994802889 @.***

 

------------------ 原始邮件 ------------------ 发件人: "arnowelzel/lightbox-photoswipe" @.>; 发送时间: 2022年9月23日(星期五) 晚上7:25 @.>; @.**@.>; 主题: Re: [arnowelzel/lightbox-photoswipe] The picture of Aliyun oss and the original picture protection option is turned on, which causes the lightbox to be incorrectly loaded in the article (Issue #93)

You can add code here as well like this, there is no need to create screenshots:

original: $exif = @exif_read_data( $file . $params, 'EXIF', true );
your version: $exif = @exif_read_data( $file, 'EXIF', true );
However - the $params paramter must be there - it is part of the URL if the image is external. Just because your images also work without any parameters this does not mean that this is always the case.

I could add an option in the backend to ignore parameters in the image URL to get the EXIF data. However: if your images work without any parameter in the URL anyway, why do you add that in the first place? In that case people just can do the same, remove the parameters and just copy the original image without watermark. Especially since the parameter is ?x-oss-process=style/watermark it is obvious that this is used to add a watermark.

So both of these images work, the second is just without watermark - but if can do that, anyone else can do this as well:

https://oss.ihooai.com/img/202209231328120.png?x-oss-process=style/watermark

https://oss.ihooai.com/img/202209231328120.png

But if the image is protected so it can not be viewed without that parameter, then this applies to my plugin as well - without getting the unprotected image there is no EXIF information available.

My recommendation: if you want to have a watermark in the images as a kind of copyright protection you should add that to the original image, so it does not need any parameters in the URL and the orignal image can not easily obtained by just removing the URL parameters.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[GHNature]

Hello, there is nothing special about the setting of Meow Lightbox, this is the screenshot 'https://oss.ihooai.com/img/1663783192722.jpg?x-oss-process=style/watermark', I am curious why it can read Take the image-protected exif. After many times of uploading pictures by controlling variables, I found that only when wordpress uploads pictures to oss storage, I upload them directly to oss through plugins, and they will not be retained on the website server. When uploading pictures in the article or selecting pictures stored in the remote oss from the wordpress media library, only in this way can the plugin Meow Lightbox read the picture exif information. Finally, thank you very much for updating the url processing rules in time, which solved the problem I debugged for a long time.

994802889 @.***

 

------------------ 原始邮件 ------------------ 发件人: "arnowelzel/lightbox-photoswipe" @.>; 发送时间: 2022年9月21日(星期三) 晚上10:21 @.>; @.**@.>; 主题: Re: [arnowelzel/lightbox-photoswipe] The picture of Aliyun oss and the original picture protection option is turned on, which causes the lightbox to be incorrectly loaded in the article (Issue #93)

Parameters like ?x-oss-process=style/watermark will be removed before the image is processed because usally the plugin is used to work with local files and not URLs.

I added a workaround to keep parameters for images loaded from "external" URLs - which means the URL in the image is not the same as the website where it used. So at least the image can be used with that URL.

However the image referred by the URL https://oss.ihooai.com/2022/09/9cd8766fefce4377181c246246733ddf.jpg?x-oss-process=style/watermark does not contain any EXIF data. I don't know, how Meow Lightbox is able to obtain the data. Did you configure something for Meow Lightbox to get the a local filename as well so it can extract the data from the local file?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>