Media files as downloads & securing them with extranet

Topics: General, Standard packages, Troubleshooting
Dec 21, 2010 at 10:06 PM

I'm trying out the extranet package via Composite V2.1 beta.

What I would like to do is upload various forms of content to the site (such things as .zip, .docx, .exe, or whatever) so that users can download them, and have them protected using extranet security as one can do with content (pages). Not just that, but have different groups allowed access to different sets of media and return a nice access denied message if they attempt to download a piece of media they do not have access to. Keep in mind that these downloads are using the "&download=true" switch on the end of the URL (without that, things such as images are just displayed in-line).

However, while this all "works" there is no friendly access denied message, one is simply presented with an exception (as below). Is this a result of me using a beta or is this kind of permissions-based downloading of files something that is not supported? 

 

Thanks!

 

The given key was not present in the dictionary.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.

 

[KeyNotFoundException: The given key was not present in the dictionary.]
   System.Collections.Generic.Dictionary`2.get_Item(TKey key) +4318751
   Composite.Community.Extranet.RenderingResponseHandler.ExtranetRenderingResponsHandler.RedirectToLoginPage(RenderingResponseHandlerResult result, Guid LoginPageId, String ProviderName, Int32 redirectReason) +241
   Composite.Community.Extranet.RenderingResponseHandler.ExtranetRenderingResponsHandler.GetDataResponseHandling(DataEntityToken requestedItemEntityToken) +5507
   Composite.Core.WebClient.Renderings.RenderingResponseHandlerFacadeImpl.GetDataResponseHandling(DataEntityToken requestedItemEntityToken) +101
   ShowMedia.ValidateAndSend(HttpContext context, IMediaFile file) +128
   ShowMedia.ProcessRequest(HttpContext context) +137
   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +597
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +266

 


Coordinator
Dec 22, 2010 at 7:11 AM

That's clearly a bug - the expected behavior would be to redirect the browser to the extranet login screen (this is somewhat hinted in the stack trace). We will fix...

 

 

Coordinator
Dec 22, 2010 at 9:00 AM

It looks like it fails to build a url to the related login page.

Until we have a fix you can check that:

1) The login page exists

2) It is published and all it's ancestor pages are also published (if parent page isn't published, it's not possible to access it's children pages by url)

3) The login page exists in all locales/cultures.

Coordinator
Dec 22, 2010 at 9:02 AM

@napernik I have confirmed this to be a bug in the beta and will send wesalcock a fix shortly :-)

Coordinator
Dec 22, 2010 at 9:39 AM

@wesalcock You have a fix in your mailbox. Also the package has been fixed, so new installs will behave as expected.

Thanks for reporting this issue!

Dec 22, 2010 at 4:06 PM

@mawtex The fix works as you suggested!

A huge thanks for the fast response and fix, this is awesome!