U4-8039 - GetBigThumbnail fails when using absolute URL from Azure BLOB storage

Created by Tony 19 Feb 2016, 14:53:37 Updated by Stephan 17 Oct 2017, 08:56:40

Tags: PR

Is duplicated by: U4-7858

Subtask of: U4-9609

After upgrading to 7.4.1, the thumbnails to images in the media library are no longer visibile. We are using the azure BLOB storage container plugin and the following URL is generated when an image is uploaded.

http://<>/umbraco/backoffice/UmbracoApi/Images/GetBigThumbnail?originalImagePath=https%3A%2F%2Fbuildagentsa.blob.core.windows.net%2Fhrp-dev-container%2F15140%2Fpenguins.jpg

Running the URL via the browser causes the following exception.

{"Message":"An error has occurred.","ExceptionMessage":"A relative URI cannot be created because the 'uriString' parameter represents an absolute URI.","ExceptionType":"System.UriFormatException","StackTrace":" at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)\r\n at Umbraco.Web.Editors.ImagesController.GetResized(String imagePath, Int32 width, String suffix)\r\n at lambda_method(Closure , Object , Object[] )\r\n at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass10.b__9(Object instance, Object[] methodParameters)\r\n at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)\r\n— End of stack trace from previous location where exception was thrown —\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Controllers.ApiControllerActionInvoker.d__0.MoveNext()\r\n— End of stack trace from previous location where exception was thrown —\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Filters.ActionFilterAttribute.d__5.MoveNext()\r\n— End of stack trace from previous location where exception was thrown —\r\n at System.Web.Http.Filters.ActionFilterAttribute.d__5.MoveNext()\r\n— End of stack trace from previous location where exception was thrown —\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Filters.ActionFilterAttribute.d__0.MoveNext()\r\n— End of stack trace from previous location where exception was thrown —\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Controllers.ActionFilterResult.d__2.MoveNext()\r\n— End of stack trace from previous location where exception was thrown —\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Filters.AuthorizationFilterAttribute.d__2.MoveNext()\r\n— End of stack trace from previous location where exception was thrown —\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.d__1.MoveNext()"}

It looks like the URL is looking for a local path to an image in the CMS rather than using a relative URL. Please can the fix inlude the ability to have both.

1 Attachments

Comments

Sebastiaan Janssen 19 Feb 2016, 15:21:11

What version did you upgrade from?


Tony 19 Feb 2016, 15:23:49

Upgraded from 7.2.5 to 7.4.1


Tony 19 Feb 2016, 15:36:14

The view in media


Sebastiaan Janssen 19 Feb 2016, 15:36:21

This is unfortunate for you, it looks like the behavior changed in 7.3.5 with this commit: https://github.com/umbraco/Umbraco-CMS/commit/e0ee786271e334116fafc58b25127caf6cc1320f

While it's a showstopper for you, you're the first to see this issue. I don't know how you've gotten things into blob storage or if you're using some kind of FileSystemProvider for that but I'd recommend you have a look at this project that people seem to be using successfully: https://github.com/JimBobSquarePants/UmbracoFileSystemProviders.Azure

I haven't investigated the error further but I'm assuming it's a security thing, generally it's a bad idea to allow people to attach URLs to a querystring that will download files.


Tony 19 Feb 2016, 15:47:45

The BLOB container is serving the media correctly to the website, so chaging providers wouldnt be the best move forward. The functionality was working correclty in the previous version, it was only when we upgraded to the new major version the problem arose.

The Problem is that in the Admin panel, the image cropper method is looking for a local file to place into the image block. We need this to also allow for a full URL to be used.

http://issues.umbraco.org/issue/U4-7858 is also having the same problem.

Run a full image path into /umbraco/backoffice/UmbracoApi/Images/GetBigThumbnail?originalImagePath= for an inmage that isnt relative to the media library and you will get the same error.


Sebastiaan Janssen 19 Feb 2016, 15:53:38

Ah I see, don't really understand the description in U4-7858.

So would it help to revert the umbracoFile field to use the datatype "Upload" again, instead of the cropper? Like it was before?


Stephen Adams 19 Feb 2016, 16:00:48

@anthony.gledhill@e3.co.uk during your upgrade, was your FileSystemProviders overwritten by chance? For #7858, my issue is just when on the detail view for the media in the Umbraco Back Office. I actually have a fix that I need to create a pull request for it. Everything else in Umbraco is fine, FWIW.


Sebastiaan Janssen 19 Feb 2016, 16:01:37

The error specifically comes from a call to GetFullPath which works in the https://github.com/JimBobSquarePants/UmbracoFileSystemProviders.Azure project because they're looking at the URL instead of a local path: https://github.com/JimBobSquarePants/UmbracoFileSystemProviders.Azure/blob/fa88203ff599f230e0249a3d1b36eef72e790d78/src/UmbracoFileSystemProviders.Azure/AzureFileSystem.cs#L429

Again, I don't know what kind of a provider you're currently using or what your setup is like, but it would be worth considering to try and switch over to this one. Unfortunately Umbraco out of the box only supports the PhysicalFileSystem provider by default and it looks like by accident this used to work well for you but we later on had a breaking change that broke your expected behavior.


Tony 19 Feb 2016, 16:08:17

Thank you for helping me out with this, I appriciate the help.

We are using https://our.umbraco.org/projects/backoffice-extensions/azure-blob-storage-provider/ for our storage provider.

We are unable to change providers as have a live site with a few thousand images.


Sebastiaan Janssen 19 Feb 2016, 16:45:05

Did you check, like Stephen said above that the FileSystemProvider wasn't overwritten? The UmbracoFileSystemProviders.Azure is actually a fork of the one you're using, upgrading might be possible (not sure), it claims to have many improvements over the older version you're using,.


Tony 19 Feb 2016, 16:57:04

We have fixed the issue with the thumbnail images. It looks like the the upgrade didn't change the image type from upload to image cropper. Once this was updated, the images re-appeared.


Shannon Deminick 10 Mar 2016, 09:27:47

There's a PR for this here: https://github.com/umbraco/Umbraco-CMS/pull/1159 But i need to have steps to reproduce to verify the fix so I'm waiting on a response from the developer of the PR


mscommunities 22 Apr 2016, 22:13:45

We are seeing the same issue using the standard Image media type with the Upload data type. We are also using the UmbracoFileSystemProviders.Azure package v0.5.0-beta, Umbraco version 7.4.1.

Sample url: https://test.azurewebsites.net/umbraco/backoffice/UmbracoApi/Images/GetBigThumbnail?originalImagePath=https%3A%2F%2Ftest.blob.core.windows.net%2Fmedia%2F5245145%2Fpluralsight-logo-4.png


Stephan 17 Oct 2017, 08:56:26

Note - I have closed the PR - accepting absolute urls such as http://cdn.example.com/media/123/image.jpg and turning them into http://cdn.example.com/media/123/image.jpg?width=200 is not going to work since there is no ImageProcessor on CDN.

For proper CDN to work with thumbs... all urls should be local ie /media/123/image.jpg and /media/123/image.jpg?width=200 and then local would redirect to the proper CDN url. The CDN url should not be exposed.

The following UmbracoFileSystemProvider.Azure issue might give more details: Image resizing in media folder not working.

So this seems due to a general configuration problem. Closing the issue now, if this is still a problem make sure to check out the documentation and to open a new issue if appropriate.


Priority: Normal

Type: Bug

State: Closed

Assignee:

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted: Pull request

Affected versions: 7.4.1

Due in version:

Sprint:

Story Points:

Cycle: 4