Apex Code Development You need to sign in to do that
Don't have an account?
hemm Profile Requirements for a RemoteAction
In Winter 12, @remoteAction methods were enhanced to allow "public" methods to be used in Visualforce controllers. That's great. I am curious about the profile requirements, though.
What I am finding is that, for non-admins, the Controller class needs to be assigned to their profile, but for admins it does not. I was under the impression that having a remote action in the main controller for a page would be enough. By the user being assigned to the Page, they'd automatically have access to that page's remote action methods, but that doesn't seem to be the case.
My main concern is that I am introducing remote actions into a managed package app and it would be likely that my users are not assigned to the controller class in their profile. I'd like to push upgrade the change so it "just works", but am worried about the side effects.
Is the requirement for apex class assignment in the Profile by design or is it a bug?
Good question!
I use remote actions pretty heavily - but have not considered the implications of 'access' per user as their profile or user settings are 'assigned to the class'.
By assigned to the class or page, I'm assuming you mean have permission to access it?
I guess I just assumed that remote methods respected permissions the same way any APEX function accessed via a VF Page request would.
If you look at a user's profile, you'll see 2 lists at the bottom. Assigned Visualforce Pages ans Assigned Apex Classes. In order for a user to access a Page, they need access to the Page on their Profile. Under most circumstances, they don't need to profile access to the Controller class on their profile. By having access to the Page, they have access to the Class because the Page uses it as a Controller.
I was implementing @remoteAction methods and all worked swimmingly during development. I then tried testing my page using a user whose Profile had less-than-admin rights. That user had access to the Visualforce Page on their profile, but not the Apex Class. They never needed it before. The remoteAction methods didn't work for them. I'd see JavaScript errors in the console about not having permissions for the controller class. I then went to their Profile and assigned them the Controller class and all worked.
The big difference is that an actionFunction (the closest thing to a remoteAction method before they existed) didn't need this level of permissions on a profile. They had access because the Page had access. With remoteAction methods, it's different.
Like you guys, we have customers out there with default profile settings for our app. Historically, they wouldn't have access to the Class on their profile. If I rollout the remoteAction methods, the page will stop working.
I am hoping this is a permissions bug that Salesforce will work out so that remoteAction methods don't have profile dependencies and act more like actionFunctions when it comes to a user's ability to use them.
Clear as mud? Thoughts?
You've definately pointed out an important consideration for us to note in our install guide. We have limited number of controller classes (intentional pre-packaging to reduce redudancy) but yes, I would have assumed that the controllers/methods would be avaliable if the page was! As long as they were declared/annotated as as 'global with sharing'
@RemoteActions are a great way for me to make quick use of JSON with my JS from within a VF Page without having to use any of the other APIs (Apex REST or REST API) - which created a lot of unecessary duplicity and extra setup requirements with RemoteSite settings.
I did some more digging. I went ahead and added 2 remote methods into my managed package and pushed the code to a subscriber org (Group Edition).
In this case, the Apex Class must be assigned to the user even if they are the system administrator. The problem here is that Group Edition doesn't have profiles and, thus, there is no method for assigning an Apex Class to a Profile!!!
This has got to be a security bug in Salesforce.
The error in the JavaScript console comes from VFRemote.js and is as follows...
Visualforce Remoting Exception: The installed managed class geopointe.Map_Controller is not visible
If Salesforce is listening, I logged Case 06715493 with Support just so its formally documented somewhere.
Hey there. Thanks for raising this issue. Salesforce.com R&D acknowledges this issue as s a bug and is actively working to resolve. Thank you.
That is great news and a load off my mind! Assuming a fix is figured out soon, is this the type of fix that would go out in a patch update or something that would need to wait until the Spring 12 release?
Spring '12.
Contact your customer support rep to escalate for patch release consideration.
Thanks for your patience.
Can you confirm what the exact bug is here please? Is it the fact that you have to grant class access to the profile (and hence make the controller global) or is it the fact that it won't work in Group Editions.
I am also experiencing this problem, but our class isn't global yet - read the docs on this and couldn't see where it says you have to make the controller global. If I make the controller global and then give all profiles access to this class will the remote action work?
The current requirement security requirement is that the class with remoteAction methods in it must be assigned to the Profile of the user to be usable. The way it should work is that, simply by being the controller for a Page, the remoteAction methods are available.
The bug is the Profile requirement.
The Group and Professional Editions issue is one for ISVs. We can run our apps in those Editions, but those Editions don't have Profiles. Even if we wanted to, we cannot assign a user to an Apex Class so they can use remoteAction methods.
The issue with Group and Professional Editions is a by-product of the larger Profile issue.
For my purposes, I have a short term workaround. It so happened that I have a class in my AppExchange package that is already assigned to Profiles, but it's not the controller class. I have added that class as an extension controller for my page and am calling remoteAction methods from it.
It should work, but I still run the risk of the Profile issue hitting me. The good news is that most/all of my customers are already assigned to that other class.
For in-house work, I'd suggest making a new class with your remoteAction methods in it and make that an extension to your page. This way, that class is isolated from the main controller.
Good Idea, I'll try that. We also have a global class that all Profiles use. I appreciate the prompt responses to my questions, thanks.
I have confirmed that the Spring 12 release fixes this issue. Any user has JavaScript access to the remoteAction methods in a Page's controller.
They only need access to the page itself (which they need anyway) and nothing else. I tested with an extremely locked down profile taking away every single permission (including API access) and all Apex Classes.
I had confirmed this in Spring 12 Sandboxes. Now that we are in Production I can confirm that this is NOT fixed for managed packaging. After spending many hours migrating to remote methods, I've been testing the use of remote methods in subscriber orgs. The error I get is
Visualforce Remoting Exception: The installed managed class namespace.myController is not visible
This is really frustrating. I am logging a case and will update the thread if I get an update.
We are actively looking into this issue. Please stay tuned.
Great. I did a bit more research. I have found that I AM able to access remoteActions if I include them in a global class as an extension to my page's controller. However, I am NOT able to access them if they are in a public class that is acting as my Page's controller. In both cases, the methods themselves are public.
Also, I have case 07221985 open if you want to communicate with me or have me test anything and keep it off the public forums.
Now that I have this new model in some subscriber orgs, I get the compilation error "Public remoted methods not allowed in global components".
I've ben trying to have remoteAction methods work in my Managed Packages since Winter 12 and it's still not possible. If we can get that core visibility issue fixed so I can put them into my public controller, I think we will be good.