Get AccessToken after Invitation API callback
Mishit
Invitaion API documentation(see below snippet) says that : Callback
result only contains user and nonce value but not the access token. It
says use Verify Permission API to get the acess token. But I do not
see any method under Verify Permission API which can return Access
Token to locate the user. Instead Get Location API has such method
called getLocationAccessToken(User user) .
Is my understanding correct and is that documention bug ?
Are we suppose to use Get Location API's getLocationAccessToken()
method once we get the invitation callback ?
Are there any other ways ?
thanks
/Mishit
Snippet from Invitaion API documentation
--------------------------------------------------
9.5.2 Receiving Notification by Callback (Push)
Since this callback can be delivered non-securely, it does not
contain the user's mobile number or access token; you will have to
keep track of the mobile number yourself (associating it with the
nonce value) and use the Verify Permission API to get the token.
---------------------------------------------------
Eli Bishop
I'm not sure I'd call it a bug, but it is at least an inconsistency in
how we organized the low-level HTTP/REST APIs versus their counterpart
methods in the SDKs. That is, in the Developer Guide - which does not
refer to any language-specific SDK methods - we described the "get the
access token" function as part of the "Verify Permission API"... but
that does not correspond exactly to the PermissionAPI class in the Java
SDK. As you guessed, the Java method you want is
GetLocationAPI.getLocationAccessToken(User).
By the way, in the next platform and SDK release, which should happen
within two weeks, we will be making some improvements to how
asynchronous callbacks work (for both invitations and asynchronous
location requests) that may make this a bit easier: Veriplace will give
you the access token (for an invitation) or the location data (for a
location request) directly in the callback, rather than through a
separate API call-- as long as you can provide a secure (https:) URL for
the callback. However, the current API will still continue to work too.
There'll be more details with the release.
best,
Eli
--
Eli Bishop
Wavemarket, Inc. / Location Labs
e...@location-labs.com
Mishit
Thank you so much for clarification.
Well, I have few other queries regarding callbacks from Veriplace.
1) Invitation Callback
- We are sending the invitation to end user and setting the
callback to our service(servlet) to be called by Veriplace once the
end user has responded.
Can someone from Veriplace check that Veriplace is trying to
reach our service but may be not able to reach because of the
firewall ?
2) When I run "basic" example shipped with SDK the UserDiscovery step
redirects me to veriplace.com for authentication and it also sets the
callback .
This callback would be my organization internal URL. How come
veriplace is able to callback to that URL if it is internal to
organization.
Or it is just asking browser to do that ?
String redirectUrl =
client.getUserDiscoveryAPI().getRedirectURL(callback);
// redirect the User Agent
response.sendRedirect(redirectUrl);
thanks
/Mishit
Eli Bishop
Please see responses below.
On Thu, 2010-09-16 at 14:01 -0700, Mishit wrote:
> Hello Eli
> Thank you so much for clarification.
> Well, I have few other queries regarding callbacks from Veriplace.
>
> 1) Invitation Callback
> - We are sending the invitation to end user and setting the
> callback to our service(servlet) to be called by Veriplace once the
> end user has responded.
> Can someone from Veriplace check that Veriplace is trying to
> reach our service but may be not able to reach because of the
> firewall ?
I can check the logs for this, but I would need to know the domain you
are using for your callbacks - the way the system log is currently
organized, I can't tell which callback is for which application.
> 2) When I run "basic" example shipped with SDK the UserDiscovery step
> redirects me to veriplace.com for authentication and it also sets the
> callback .
> This callback would be my organization internal URL. How come
> veriplace is able to callback to that URL if it is internal to
> organization.
> Or it is just asking browser to do that ?
Right, it's just asking the browser to do it. The terminology is a
little confusing - this is not a "callback" in the same sense, i.e. it
is not server-to-server; it is a browser redirect from veriplace.com
back to your application's URL.
best,
Eli
Eli Bishop
After sending my other reply yesterday, I realized that I made a mistake
when I said the following:
> By the way, in the next platform and SDK release, which should happen
> within two weeks, we will be making some improvements to how
> asynchronous callbacks work (for both invitations and asynchronous
> location requests) that may make this a bit easier: Veriplace will give
> you the access token (for an invitation) or the location data (for a
> location request) directly in the callback, rather than through a
> separate API call-- as long as you can provide a secure (https:) URL for
> the callback. However, the current API will still continue to work too.
> There'll be more details with the release.
I got my releases mixed up-- this feature was actually added in the
*last* release! So if you are using the latest (2.8) version of the
Java SDK, and if you can provide a secure URL for callbacks (your server
has an SSL certificate), then you can already do this.
There are more details in the API documentation for the new class
com.veriplace.client.CallbackOptions, and the overloaded method
InvitationAPI.inviteGetLocation(String, boolean, CallbackOptions), but
basically the way the new mode works is as follows:
1. When you call inviteGetLocation, instead of passing just a string for
your callback URL, pass a CallbackOptions instance which you've created
with "CallbackOptions.createExtendedCallback(url)".
2. When you get the callback, you will call
InvitationAPI.getCallbackResult() exactly as before, but now the
InvitationStatus object that this method returns will have more
properties available: its getAccessToken() method will return the newly
created permission token, and getMobileNumber() will return the mobile
number the invitation was sent to.
The same new mode is also available for asynchronous location requests,
with the same restrictions, i.e. Veriplace will only send protected
information such as tokens and location data if it can use SSL.
best,
Eli
Mishit
1) Invitation Callback
We are passing "portali.hughestelematics.com" domain in our callback.
Can you please verify that veriplace is try the invitation callback to
this domain?
We haven't received any callaback yet.
And about new release 2.8 - yeah I saw that callback mechanism has
more options now.
In fact above example is using the 2.8 SDK APIs only.
Eli Bishop
Yes, I do see callback attempts to that domain. It's returning an HTTP
500 error, with the following message:
Can't connect to atlsblsohd.hti.com:7777 (Bad hostname
'atlsblsohd.hti.com')
NB, the .hti.com domain is not one we're trying to connect to - it looks
like your own gateway is trying to forward to it and it doesn't exist.
best,
Eli
On Mon, 2010-09-20 at 09:16 -0700, Mishit wrote:
> Hello Eli
> 1) Invitation Callback
> We are passing "portali.hughestelematics.com" domain in our callback.
> Can you please verify that veriplace is try the invitation callback to
> this domain?
> We haven't received any callaback yet.
--
Mishit
Thanks for the log. Looks like the way we are redirecting the
veriplace request from our gateway to our internal server has some
problems.
We are looking into different ways to achieve this. Basically we have
one HTTP server outside our DMZ zone and it can re-direct HTTP
requests to internal servers.
thanks
/Mishit