|
POST
|
Hi Robert: Both the "info" set and "export" set are HTTPS. I'll add an HTTP rule and see of that changes anything...
... View more
09-11-2018
10:20 AM
|
0
|
0
|
2808
|
|
POST
|
Hi All I have a WAB 2.7 app (self deployed) that accesses a webmap with a secured arcgis server token service. The webamp will load correctly but the secure layer won't draw. Watching the network traffic, this makes sense b/c the 'export' image request to the service is NOT routed via the proxy. Setup and things I can confirm: The proxy is correctly setup and configured: loclahost/proxy.ashx?ping returns the expected json response localhost/proxy.ashx?https://myserver/myservice/.... all return the correct response when I manually copy/paste the requests to the browser bar The WAB app config file has at least some of the config correct. I'm using the "rules" section for the specific secure service url. Without the rule for the specific secure service, the login/token prompt is displayed. With the rule in place the login dialog does NOT appear and watching the network traffic, I see a bunch of /info?=json requests for the service routed via the proxy. Config: "httpProxy": { "alwaysUseProxy": false, "url": "http://localhost/proxy.ashx", "useProxy": true, "rules": [ { "urlPrefix": "https://streams.whitestar.com/arcgis/rest/services", "proxyUrl": "http://localhost/proxy.ashx" } ] }, Network details The WAB correctly uses the proxy when the webmap is loading and getting service/layer info. These request all return 200 success and the JSON is visible in the response preview: locallhost/proxy.ashx?https://streams.whitestar.com/arcgis/rest/services/omnitrax/WS_Parcels_OMNITRAX/MapServer?f=json locallhost/proxy.ashx?https://streams.whitestar.com/arcgis/rest/services/omnitrax/WS_Parcels_OMNITRAX/MapServer/layers?f=json locallhost/proxy.ashx?https://streams.whitestar.com/arcgis/rest/services/omnitrax/WS_Parcels_OMNITRAX/MapServer/0?f=json locallhost/proxy.ashx?https://streams.whitestar.com/arcgis/rest/services/omnitrax/WS_Parcels_OMNITRAX/MapServer/1?f=json locallhost/proxy.ashx?https://streams.whitestar.com/arcgis/rest/services/omnitrax/WS_Parcels_OMNITRAX/MapServer/2?f=json The the layer list checkbox is clicked on, the following requests to export function are not routed thru the proxy and return the "token required" json instead of an image: streams.whitestar.com/arcgis/rest/services/omnitrax/WS_Parcels_OMNITRAX/MapServer/export?dpi=96&transparent=true&format=png32&layers=show%3A0%2C1%2C2&bbox=-15859205.762025328%2C3291557.064882444%2C-6735682.065909116%2C7826413.078984177&bboxSR=102100&imageSR=102100&size=1865%2C927&f=image What am missing? Thanks
... View more
09-11-2018
10:13 AM
|
0
|
4
|
2993
|
|
POST
|
Looks like it's an issue within the Esri proxy resource code. See this github issue ticket: 304 Responses should not contain a body · Issue #488 · Esri/resource-proxy · GitHub Essentially the firewall/load balance clips the body of the 304 response as per the spec but since the ags/proxy were returning a body ...
... View more
08-24-2018
01:13 PM
|
0
|
2
|
2267
|
|
POST
|
Little more testing details: We configured the "proxy logging" with verbose level... from the log it appears the traffic makes it all the way through the sequence of the proxy... I see the requests come into the proxy and appear to be returned from the map service as 304 (logged as "server error, response 304")... This seems to indicate that the proxy is working correctly but something at the public firewall/load balancer is killing the requests on the way back out.
... View more
08-22-2018
10:35 AM
|
0
|
0
|
2267
|
|
POST
|
Hi All, I've got an odd issue that I can easily reproduce in a specific environment. It's slightly complicated to explain ... Short version: JavaScript API requests to a map service (legend, query and export) fail after the first successful attempt. The response is a 504. Using fiddler to trace these request, I've narrowed it down to the IF-NONE-MATCH header in the request. Using fiddler, I reproduce the failures, then remove this header value and the requests will process successfully. It appears to me that some interaction between the proxy, firewalls, arcgis server, etc are having a mis-communication for these request that would probably result in a 304 type response. I don't control the network, firewall environment so I might be missing some details but this is my view of the setup: INTERNET | V PUBLIC FIREWALL | V LOAD BALANCER | V DMZ WEB SERVER (x2 i think) * web app/site + proxy * arcgis web adapter site | V INTERNAL FIREWALL | V ARCGIS SERVER (v10.5) * secure map service Here's the sequence of events I've traced so far and can reliably and consistently reproduce: 1. Start with a cleared browser cache or in-private browser window 2. Load web app/site in browser.. * all the web site resources (html, css, js etc) load correctly * AGS REST API requests kick off and are successful: * https://{mywebserver/site}/proxy.ashx?https://{myarcgiswebadpater/service}/MapServer/3/query?f=json... * https://{mywebserver/site}/proxy.ashx?https://{myarcgiswebadpater/service}/MapServer/export?f=image... * https://{mywebserver/site}/proxy.ashx?https://{myarcgiswebadpater/service}/MapServer/legend?f=json... NOTE: none of these requests have an IF-NONE-MATCH header in the request and all have a ETAG header with a specific value in the response 3. Refresh the web app using the default browser button * all the web site resources (html, css, js etc) load correctly * AGS REST API requests kick off and all FAIL - status 504 NOTE: in each request there is now a IF-NONE-MATCH header in the request with a value that corresponds to the ETAG from the equivalent request in step #2. When I trap these requests in Fiddler and remove the IF-NONE-MATCH header, they'll execute successfully. A few more details: * Step #3 will continue to fail until a full browser cache clear or new in-private window...obvisouly since the caching is reset. It does appear to reset after some minutes interval but I haven't narrowed down the time window. * When I run the website from my local dev machine or test server (web app and proxy) directed to the live map service, the refreshes will correctly load, the request headers are identical and the responses have 304 status codes. This seems like normal browser/internet caching stuff and it works correctly from an outside web server so I'm guessing something in the hosting environment isn't configured correctly to rematch these caching requests? Anyone have suggestions on what settings or tweaks I can pass along to the network ops staff that might remedy the current situation? Thanks!!!
... View more
08-14-2018
05:15 PM
|
0
|
4
|
3006
|
|
IDEA
|
See my discussion here: https://community.esri.com/thread/215959-how-do-we-smooth-out-the-self-hosted-wab-app-and-the-oauth-approve-workflow for details... but essentially when you self-host WAB apps that connect to secure portal webmaps, the user is forced to jump thru a lot of login dialogs. This can be simplified by changing the portal mode from "pop-up" to "in-page" but that setting is hard-coded in the tokenUtils file. A simple extra true/false setting in the config could allow for this to be changed.
... View more
06-25-2018
01:29 PM
|
4
|
0
|
615
|
|
POST
|
A little more digging and I connected some dots... The "Please Sign On" dialog is browser gimmick to beat the pop-up blockers. If the user initiates the pop-up from a dialog action, the browser doesn't block the "sign/approve" portal dialog. You can see this in the API documents: So the solution is to change the portal configuration to use the 'in-page' mode for authorization rather than the "pop-up" mode. This is set with on OAuthoInfo:popup property. In WAB 2.7, this hard coded in jimu.js/tokenUtils.js line 416. Change from true to false. Now when the app loads it will skip "please sign-in" dialog. If you're logged into your portal and the 'auto-approve' is set as noted above, the app loads right away cleanly. If not logged in or not 'auto-approved', the portal dialog will load inside the main page rather than the pop-up, which isn't as nice.
... View more
06-25-2018
01:22 PM
|
2
|
0
|
1364
|
|
POST
|
I just ran into this issue... oddly it appears to be different if the database is 'geodatabase enabled' or not ... at least on SQL Server. I just created a table via ArcCatalog on a plain/non-geodatabase database connection and the OBJECTID column is set as the primary key by default.
... View more
06-12-2018
03:16 PM
|
1
|
0
|
4176
|
|
POST
|
Thanks Andrew, Let me give that second script a try. I didn't think about trying the arcpy method. If that single method handles overwrite it might work for us but the admins don't usually have 'desktop' bits installed hence the use of the web manager. Does the new python api handle this situation? I might drop a "allow overwrite in web manager" in the ideas forum.
... View more
06-12-2018
07:49 AM
|
0
|
2
|
1498
|
|
POST
|
Hi All, I have a server environment where we publish services via the 'create service definition - no server connection" in ArcMap, hand the .SD file off to an admin that then publishes the service via the web manager. There's the option to 'overwrite a service' from ArcMap but it seems like this is only avialable for the connected workflow. Is this process just a wizard that does the following steps in automation: 1. Create service definition 2. Import from existing service 3. Delete existing 4. Publish new So our workflow to "overwrite" in this disconnected environment is those 4 manual steps or is there a shortcut? Thanks Fred
... View more
06-07-2018
10:41 AM
|
0
|
4
|
2217
|
|
POST
|
Hi Andrew, Thanks for the reply... It's definitely an HTTP connection but HTTPS is also enabled. Of course it's working smoothly now. I'll try those things next time I run into it the issue. It was likely the publishing patch. We upgraded everything to 10.6 (desktop and server). I can't remember if we did the upgrade before or after I posted the question. For now I'll chalk it up to "old bug/fixed in current release" until I comes back up. Have a good day Fred
... View more
06-07-2018
10:21 AM
|
0
|
1
|
4705
|
|
POST
|
In the organization portal setting, at the bottom of the general tab there's an option to ADD APP to teh App Launcher. This allows the app to skip thru the "Approve" dialog. I still get the "Please Sign On" dialog, which doesn't make sense since I'm already signed in.
... View more
06-06-2018
09:53 AM
|
2
|
2
|
1364
|
|
POST
|
We have number of self hosted JavaScript applications with custom widgets and functionality (these have to be self hosted correct?). The users are getting pretty annoyed with the extra clicks when opening these apps. Right now they generally access the apps from links on the portal banner so they are already signed into the online portal. When the browser tab opens, the application frame is loaded, then they are presented with a simple "Please sign in to continue" dialog which then takes them to a pop-up web page with the "ThisApp wants to access your ArcGIS Online account information" Approve dialog. * How do we make this a simpler user experience? * Can we add code to get thru these dialogs with at least one click rather than two? * Why can't it "remember" that the user has Approved the app access? * Do we need run a local portal to make this workflow smooth? * We like using the online portal to create and store the "web maps" but that little bit of niceness for the admins is less a priority over the actual user experience so maybe we should drop using online web map for self hosted apps? I'm open to anything that make this smoother for the user i.e. they should only have to login once per session and approve once per application. We can add code, proxies, wrappers etc... thanks Fred
... View more
06-05-2018
10:04 AM
|
0
|
3
|
1608
|
|
POST
|
One last comment --- sorry about my OCD on this one, I'm trying to put together a small training for newbies on the REST SDK and really wanted to use this page/function in a demonstration --- it looks like the offending file is here: [INSTALLDIR]\ArcGIS\Server\framework\runtime\tomcat\webapps\arcgis#rest\www\client\mapserver\query.jsp Modify the returnExtentsOnly to returnExtentOnly and the form starts working as expected. There's one other file that appears to have the same issue: [INSTALLDIR]\ArcGIS\Server\framework\runtime\tomcat\work\Catalina\localhost\arcgis#rest\org\apache\jsp\www\client\mapserver\query_jsp.java
... View more
05-25-2018
10:36 AM
|
0
|
0
|
2153
|
|
POST
|
Alright ... looks like it's a typo on the MapService\Layer\Query form for this value. The radio buttons have a plural name for this form value instead of a singular --- returnExtentsOnly instead of returnExtentOnly If you modify these values in the source inspector or the url after a get button click, the expected results is returned.
... View more
05-25-2018
10:12 AM
|
1
|
1
|
2153
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 02-15-2024 10:18 AM | |
| 1 | 06-05-2025 08:06 AM | |
| 1 | 04-03-2024 08:47 AM | |
| 1 | 06-12-2018 03:16 PM | |
| 1 | 09-14-2023 01:54 PM |
| Online Status |
Offline
|
| Date Last Visited |
12-01-2025
12:52 PM
|