7

I'm getting dinged in the security review for passing my package namespace prefix back in the state parameter of the OAuth callback.

https://login.salesforce.com/services/oauth2/authorize?response_type=code&state=" + '{! namespacePrefix}' + "&client_id=myClientIdHere&redirect_uri=" + '{! URLENCODE(activeOauthCallback)}

I've already looked at questions like this (Determining Namespace Prefix in JavaScript and Apex) which explain how to determine the namespace, but that doesn't help me because I need to figure out how to pass the namespace back to my server during or immediately before or after my OAuth flow.

My integration needs this prefix information to be able to make OAuth'ed API calls back to a custom rest endpoint I defined in the package. How am I supposed to get the package namespace into my 3rd party platform?

5
  • 3
    Something more is going on here as the namespace is not a secret or sensitive . It may be a simple resolution to either respond with a comment as to why it is needed or set up a call during security office hours to explain.
    – Eric
    Aug 24, 2016 at 22:40
  • Well, originally I was passing the email address and the namespace prefix so maybe they were flagging the email bit. But I thought to be on the safeside I would find an alternate solution for both. My solution for determining the users email address is going to be to make a SOQL query to the sObject 'User' immediately after the OAuth flow completes. Is there something similar I can do for namespace prefix? Aug 24, 2016 at 22:44
  • A bit confused as to why you need the namespace as your managed package is initiating the oAuth correct. Should you not already know the namespace? What is your goal here? Knowing that might help us get a solution for you
    – Eric
    Aug 24, 2016 at 23:13
  • It's an OAuth flow so the goal is to get the user's access token so I can make API calls on their behalf. One of the first API calls I try to make (once I have the access token) is to a custom Rest endpoint in my managed package to store some secure settings my managed package needs to operate. However, as you know, custom rest endpoints are namespaced by the package prefix, so if I don't have that, I don't know the URL to make a POST back to from my server. Aug 24, 2016 at 23:48
  • In response to your other comment "why you need the namespace as your managed package is initiating the oAuth correct. Should you not already know the namespace" You are correct, my managed package on salesforce knows the namespace, yes. But that's not what I need. I need my 3rd party server which is receiving the OAuth callback to know the package namespace, so that it may make an API POST call back to the custom Rest endpoint in the managed package. Aug 24, 2016 at 23:51

3 Answers 3

7
+100

My solution for determining the users email address is going to be to make a SOQL query to the sObject 'User' immediately after the OAuth flow completes. Is there something similar I can do for namespace prefix?

Yes, since Spring `16 you can query Organization.NamespacePrefix in SOQL.

SELECT NamespacePrefix FROM Organization

It's a bit more work, but you can also use the MetadataAPI.describeMetadata() result DescribeMetadataResult.organizationNamespace


It seems really odd that you even need to resolve the namespace of the managed package. This is fixed for the managed package in every org. It will be the same everywhere.

If for some reason you do need to resolve the namespace and you know the API name of the Apex class that exposes the custom REST endpoint then you could query the ApexClass records to get the NamespacePrefix that it is using.

2
  • 1
    But for a custom rest endpoint in a managed package I actually need the managed package namespace prefix, not the Organization namespace prefix Aug 25, 2016 at 3:06
  • @user1813867 Wouldn't the managed package namespace be static? It doesn't change. Or are you trying to access a common REST web service across multiple managed packages? Aug 25, 2016 at 10:02
4

Insecure Storage of Sensitive Data refers to storage of passwords in insecure locations such as unencrypted custom fields or public custom settings.

It has nothing to do with transport (even of sensitive data). Moreover namespace prefixes and redirect URIs are not sensitive data in the sense above.

Either you are not correctly describing the issue or this is a false positive.

Please message me with the app name.

1
  • Yeah this sounded like a false positive to me but I was not brave enough to answer that.
    – Adrian Larson
    Aug 25, 2016 at 12:17
1

Use a post install script to populate a Protected custom setting with the Package Namespace .

This you can easily get it using Namespace of the class .Now use the protected custom setting as a merge field on the visualforce using

{!$Setup.NamespaceSettings__c.Prefix__c}
2
  • but if Security Review is throwing a fit over putting the Namespace in the state parameter, storing it in a custom setting and putting that in the state parameter would still cause them to throw a fit. I think this is going to come down to having a discussion with the security review folks to clear it up
    – Eric
    Aug 25, 2016 at 5:42
  • Protected custom setting with encoded parameter should be enough .I still do not think it's namespace that security team is holding it off for ,might be something else as well. Aug 25, 2016 at 5:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .