+ Start a Discussion
TehNrdTehNrd 

What is the best way to login Apex web services users?

I'm curious what is the best way to login and authenticate users for Apex methods exposed as web services. Should the user just login with the partner or enterprise wsdl login operations?

 

The problem I see with this approach is the serverURL retruned with these login operations is something like: https://cs2-api.salesforce.com/services/Soap/u/23.0/00DR0000000GHhW .

 

Yet the URL in the wsdl for my Apex web service is something like this: https://cs2-api.salesforce.com/services/Soap/class/ClassName. 

 

Unless I am missing something you have to eithe...

A) hardcode the apex url or

B) Extract the base URL returned form the login response so you get the right instance and then store and append the relative Apex part of the url.

 

Thoughts? Insights?

 

I'm thinking of creating an idea so that wsdls created from Apex methods also have some basic operations like login.

 

Thanks,

Jason

ca_peterson_oldca_peterson_old

As an ISV I've always been stuck with option B. I end up with some ugly, but functional code like so (C#):

 

LoginResult lr = binding.login(username, password);
                binding.SessionHeaderValue = new sforce1.SessionHeader();
                binding.SessionHeaderValue.sessionId = lr.sessionId;
                binding.Url = lr.serverUrl;
                apexConnection.SessionHeaderValue = new loader.SessionHeader();
                System.Uri sforceUrl = new System.Uri(lr.serverUrl);
                System.Uri apexUrl = new System.Uri(CIloader.Url);
                apexConnection.Url = sforceUrl.Scheme + "://" + sforceUrl.Host + apexUrl.PathAndQuery;
                apexConnection.SessionHeaderValue.sessionId = lr.sessionId;
                this.connected = true;
                return true;
SuperfellSuperfell

The Apex dervied WSDL already has the correct server URL populated in it, you can just set the session header and go.

ca_peterson_oldca_peterson_old

Ha, you're right as always Simon. Not an option for ISVs, but it should work for enterprise customers.

TehNrdTehNrd

That's true, so I guess the URL isn't really an issue, it's more of a login issue. Should have been more clear in orginal submission.

 

We have external portal users that will be consuming this apex webservice. Here are the options I see for the login part.

 

1) Provide enterprise wsdl with tons of in your face metadata

2) Provide partner wsdl, meta data still accessable but not obvious

3) Provide documentation with basic XML for consuming the login operation.

 

Sure, with all of these approaches they could eventually get to the meta data but I'm trying to not make it easy.

 

-Jason

SuperfellSuperfell

4) Tell them to use one of the OAuth2 flows for login.

TehNrdTehNrd

At first I thought, "Oh boy, I am going to have to explain how OAuth works to our partners".

 

Then I saw there is an OAuth 2.0 Username Password flow! Sweet, stupid simple.

 

Sort of defeats the purpose of OAuth but I'm not in a position to provide external OAuth support.

 

I think I owe SimonF about 10 beers.

 

Thanks,

Jason

TehNrdTehNrd

Actually, unless I am missing something the username/password flow is what needs to be used in this case. Partners will be interacting with this webservice systematically. There will be no web front end, no user user interacting on a web page, or application. So the flows that use redirects to have users enter credentials wouldn't work because there is no "user".