Select to view content in your preferred language

Secured service with token and dynamic insert in map

5865
11
05-27-2010 10:58 PM
GiosiaPoma
Regular Contributor
Hi everybody,
I'm trying, in a simple example, to add a secured service with token in a map.

At the moment I don't use https protocol. All is on http.

That's my workflow of the mxml file, all this steps are made in actionscript:

1. When the application is creationComplete I make a request to the token service with user, pass, clientid and expiration time
2. When the token is generated, I have the correct string in my handler and with this token I create a new ArcGISDynamicMapServiceLayer with the url and token.
3. Add the new object to the map with addLayer

In code:
var token:String = RequestToken('user','password');
var layerProtected:ArcGISDynamicMapServiceLayer = new ArcGISDynamicMapServiceLayer("http://server/arcgis/rest/services/service1/MapServer", null, token);
mappa.addLayer(layerProtected);

--> result: no secured service on my map. Error token not valid
This is the response viewed with Firebug when I try to make the request to the protected service:
{"error":{"code":498,"message":"Invalid token","details":[]}}

But If I try to use the previous generated token in a simple mxml file with tags <esri:ArcGISDynamicMapServiceLayer and I insert the token in the attribute of the above tag the map is shown...
In code:
<esri:ArcGISDynamicMapServiceLayer url="http://server/arcgis/rest/services/service1/MapServer" token="CRnSk2v0ukFyP87T97Yh_10IQCLhj6uBBlSwwmVXPszYSxDMBM4FdejQzqPWDEJNuzuTyt1pteZHgO0jTxvIKXG_6J4Mq0QQJoU1KQWbpEw."/>

What's the issue? What's my mistake? Have you any suggestions?
Tags (2)
0 Kudos
11 Replies
GiosiaPoma
Regular Contributor
Hi,
I didn't checked this token request with 10.1 because we still on 10 now. I don't think that your problem are about ssl... I think that your request isn't correct or the clientid isn't good. Try to check a ip solution.

With ssl certificate you encrypt comunication between client and server and you don't close other services that are unprotected... For close all service you need to apply security to all services. I hope that I've answered to your question.


I don't yet have an ssl certificate, although I am planning to get that part taken care of soon.  I have used the suggested methods above and at one point "I swear" it was working.  Now that I have programed the rest of my site it has quit working.  I am at Server 10.1.  If I send:
http.url="http://xxxxxxx/arcgis/tokens/arcgis/tokens?request=gettoken&username="+username+"&password="+password;

I get a valid token.  If I add clientid or expiration to this url, I get invalid tokens.  Am I getting invalid tokens b/c I don't yet have the certificate set up? or are the issues with my security settings on the service or server side? or by any chance is this just how it works at 10.1? 

Also, can anyone tell me if I set up the SSL will it affect my nonsecure services.  Or in otherwords, once I get the SSL certificate running is it going to shut down my sites that are not using tokens.  Might seem like a silly question, but I've made assumptions before and I am fumbling through this security stuff.  Thanks in advance!!
0 Kudos
KathleenBrenkert
Regular Contributor
I'm not certain what you mean by ip solution.
I've used this:
var rootURL:String=mx.core.Application.application.url.substr(0,mx.core.Application.application.url.indexOf("/",8));
var expir:int=1440;
var param:Object={"request":"gettoken","username":username, "password": password, "clientid":"ref."+rootURL,"expiration":expir}

I do get a token back, but it's invalid.  I get warnings from flashbuilder on my mx.core.Application as well. 
I wonder if it is 10.1.  This current project does not really need to be secure, but I want to get this right so I can secure projects that require security.  Am I losing the security by not passing the clientID and expiration?  I have time limits set on tokens on the server side.  I did not use tokens before 10.1 so I'm not certain what settings have changed.

Thank you for your info on SSL certificates.  It's what I had assumed, but it was nice to know I wasn't assuming wrong!
0 Kudos