Select to view content in your preferred language

Layers List causing permissions error

1170
14
Jump to solution
07-17-2017 01:28 PM
JamesCrandall
MVP Frequent Contributor

On loading of WAB app created in WAB Developer 2.3 I am getting a error.  How would I track down the source of this?

This only occurs when Layers List widget is included.  All layers in the source web map are set to public share.

0 Kudos
1 Solution

Accepted Solutions
JamesCrandall
MVP Frequent Contributor

The "fix" is to update the \jimu.js\tokenUtils.js file 

Line 350 changes to: 

                def = esriNS.id.getCredential(sharingUrl, { oAuthPopupConfirmation: false });

 

Line 382 changes to:

                popup: false,

View solution in original post

14 Replies
JamesCrandall
MVP Frequent Contributor

As a test, I only have the LayersList and Legend widgets in the deployed application.  I've also removed all layers/map services from the source web map.

I still receive the error above!

Any idea what is causing this permissions issue?

Also, I've been told that the IIS has .woff, .woff2 and .svg mime types added but I'm not sure if there is a proxy issue.  I've been attempting to simply add these references in the web.config but unsure if they have any affect:

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<system.webServer>

<staticContent>

<!-- Configure site to serve JSON files -->

<remove fileExtension=".json" />

<mimeMap fileExtension=".json" mimeType="application/json" />

<!-- Configure site to serve font files -->

<remove fileExtension=".otf" />

<mimeMap fileExtension=".otf" mimeType="font/otf" />

<!--more font files -->

<remove fileExtension=".svg" />

<mimeMap fileExtension=".svg" mimeType="image/svg+xml" />

<remove fileExtension=".woff" />

<mimeMap fileExtension=".woff" mimeType="application/font-woff" />

<remove fileExtension=".woff2" />

<mimeMap fileExtension=".woff2" mimeType="application/font-woff2" />

</staticContent>

</system.webServer>

</configuration>

0 Kudos
JamesCrandall
MVP Frequent Contributor

A colleague imported the app into his WAB Developer, saved it out and deployed it on the same IIS box (different url), it does not have this behavior. 

Something is wrong with my install of WAB Developer I suppose.

0 Kudos
DavidColey
Honored Contributor

Hi Jamie - this suggests that either all of your layers are not shared the same, or that if you do have org-only or group-only layers in your web map then you have to account for that in your proxy.config:

<serverUrl url="https://utility.arcgis.com"
       username="yourname"
       password="yourpassword"
       matchAll="true"/> <!-- For my referenced feature services with stored credentials-->
 <serverUrl url="https://services3.arcgis.com" 
      username="yourname"
      password="yourpassword"
       matchAll="true"/> <!-- For my hosted feature services -->

The font types above will throw an error if you hadn't added those mimes but you have so . . . 

0 Kudos
JamesCrandall
MVP Frequent Contributor

Hi David!

In an effort to eliminate that possibility from the equation, I removed all services from the web map!  It's totally empty!

I've got a ESRI support case working now -- I suspect it has to do with the fact that my AGOL account is an admin role and perhaps applying some extra level of security to any WAB that I build and deploy.  Another developer here without that admin role does not get this secondary login challenge with his WAB deployments.

Good to hear from you!

Take care.

0 Kudos
DavidColey
Honored Contributor

Yeah good to see your name come up!  Hmm, is your deployed wab registered, has a client id and client secret?  In your config do you have your appID and cross origin params set?

"appId": "YourAppID",
 "authorizedCrossOriginDomains": ["ags.yourdomain.net"],
0 Kudos
JamesCrandall
MVP Frequent Contributor

In your config do you have your appID and cross origin params set?

Yes and  unknown.  Yes, appId is set.  Will check on the cross domain attribute -- that's not something we've ever looked at or had to consider in our workflow.

Thanks!

0 Kudos
DavidColey
Honored Contributor

Yeah I would look at that, it solved issues for my apps' inability in some (but not all) cases to get past the scgov.net proxy to my dotNet proxy . . . 

0 Kudos
JamesCrandall
MVP Frequent Contributor

The "fix" is to update the \jimu.js\tokenUtils.js file 

Line 350 changes to: 

                def = esriNS.id.getCredential(sharingUrl, { oAuthPopupConfirmation: false });

 

Line 382 changes to:

                popup: false,

DavidColey
Honored Contributor

yeah but you shouldn't have had to do that, unless maybe you were trying to deploy your registered development app to IIS?