3

First, I do not have this issue with images since by marking them as Externally Available allows them to be accessed from the ImageServer servlet which does not have this problem.

Second, to reproduce this you must clear out your cache, cookies, restart the browser, etc. to ensure that you are not logged in to an SF org as your "normal" dev user. If you don't have everything set up just right, you will not be able to reproduce it.

I have a customized Force.com site and Customer Portal working together in a sanbox. The portal users are High Volume Customer Portal users. Some pages require no authentication (i.e., public/guest) and some require authentication. I'm having an issue where the authenticated user cannot see Documents files (e.g., a pdf), even though the guest/public user can.

Here's what's happening:

  1. Guest/public user clicks the link that was created with <apex:outputLink> with a value of /servlet/servlet.FileDownload?file=<recId> and sees the pdf because I set up sharing on the folder that the file is in to include the Guest User. No problem.
  2. User logs in becoming an authenticated HVCP user.
  3. User clicks on that same link on that same page and they get a Insufficient Privileges error. PROBLEM!!!

According to http://login.salesforce.com/help/doc/en/customer_portal_manage_users.htm the HVCP User cannot be included in sharing rules for Documents; however, it seems like there should be some way for them to view it since the use case I've described seems completely reasonable that if the whole world (i.e., guest user) can see the document the authenticated user should be able to as well.

I do see All Users and All Customer Portal Users as options on the folder share. I tried that, but it didn't work, I assume, because it doesn't include the HVCP licensed users, since they cannot be included in sharing rules.

Both the portal profile and the guest/public profile have Read CRUD set on the Documents.

How can I get the authenticated High Volume Portal user to be able to see the Document? I feel like I must just be missing something obvious.

Am I missing something? Has anyone had to handle this situation? Is there a known solution?

Thanks.

4

Should definitely try to look for the 500 error first as ebt stated. However, posting the answer that "solved it" for me.

  1. Set the folder as accessible to all users (probably want it to be read only as well).
  2. Mark the PDF as an Externally Available Image. This one's odd because that checkbox does not show up on the view detail page of the Document record, but it does show up on the Edit page.
  3. Reference the image in links as yourUrl/servlet/servlet.ImageServer?oid=yourOid&id=docId
  • It's worth noting that the link to the document can be accessed by anybody who figures out the URL, even if they're not logged into your SF portal, so this is probably not a good idea with highly confidential information. – ca_peterson Sep 13 '12 at 16:10
  • @ca_peterson - Great point. In this scenario it was just public documents that the authenticated user couldn't see, so it was OK, but I agree that this is NOT a good idea for anything that is not for public consumption. – Peter Knolle Sep 13 '12 at 16:34
1

note that Insufficient Privileges doesn't necessarily mean that the user doesnt have the rights to access the file. It could also be that the link is generating a 500 error, but the user does not have permission to view the exception page. This is usually what happens on public portal pages and the ilk, if my memory serves.

See if you can re-create the issue logged in as administrator and turn on the debug listener. Barring that,I would open a ticket with SF support, the link is directly tied to one of their sub-systems, not much room for tinkering on your part.

  • Good idea, but it didn't pan out. I don't get the 500 error with other users clicking the link. I am actually able to work around this by marking the PDF as an externally available image and then use the ImageServer servlet to reference it. It is strange because it isn't even an image. What's odd is I think that what I observed with not being able to access it before is actually consistent with the documentation that I waded through...it's just that it seems like SF missed this use case somehow. – Peter Knolle Aug 9 '12 at 22:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.