Strange/wrong HTTP requests performed while saving a map

[tdipisa]

Description

Wen saving a map some strange (probably wrong) HTTP requests are performed.

As soon as you open the Save modal window, the following GetLegendGraphic request is performed (even if it shouldn't ) moreover with a wrong authkey if the user is authenticated:

https://gs-stable.geo-solutions.it/geoserver/wms?service=WMS&request=GetLegendGraphic&format=image%2Fpng&height=50&width=100&layer=gs%3Aus_states&style=pophade&version=1.3.0&SLD_VERSION=1.1.0&LEGEND_OPTIONS=forceLabels%3Aon&LANGUAGE=en&SCALE=9028&authkey=

After saving the map some other requests to geostore are performed (and also these ones shouldn't):

https://dev-mapstore.geosolutionsgroup.com/mapstore/rest/geostore/extjs/resource/32724
https://dev-mapstore.geosolutionsgroup.com/mapstore/rest/geostore/extjs/resource/23110
https://dev-mapstore.geosolutionsgroup.com/mapstore/rest/geostore/extjs/resource/32556
https://dev-mapstore.geosolutionsgroup.com/mapstore/rest/geostore/extjs/resource/24365
https://dev-mapstore.geosolutionsgroup.com/mapstore/rest/geostore/extjs/resource/32659
https://dev-mapstore.geosolutionsgroup.com/mapstore/rest/geostore/extjs/resource/34428
https://dev-mapstore.geosolutionsgroup.com/mapstore/rest/geostore/extjs/resource/32724

Response code is HTTP 404

How to reproduce

• Reproduced with this map

Expected Result

No wrong (and especially failing) requests are performed while saving a map

Current Result

• Not browser related

Browser info

(use this site: https://www.whatsmybrowser.org/ for non expert users)

Browser Affected	Version
Internet Explorer
Edge
Chrome
Firefox
Safari

Other useful information

This problem seems affecting both DEV and QA

[DavidQuartz]

@tdipisa I am unable to reproduce the issue. From my tests, opening the Save Modal triggers only 2 (details, and permissions) which seem to be expected. After saving, there are no requests to geostore. And every request throughout my tests have been successful.

Could there be any additional information which may help to reproduce the issue?

Just in case this is important: I first had to do a Save As to be able to do a Save. So the tests have been with my version of the map since I do not have permission to execute a direct Save on the original map.

[offtherailz]

Hi @DavidQuartz, Did you performed the test on your local machine?
Maybe this problem affects only dev instance that already contain many maps, dashboards, geostories and contexts.

[DavidQuartz]

@offtherailz I performed the test on both the dev instance and on my local machine. I've attached a gif from the dev instance.

[tdipisa]

@offtherailz I performed the test on both the dev instance and on my local machine. I've attached a gif from the dev instance.

@DavidQuartz look better the GIF I provided in description. You have to look at Console not Network tab.

[DavidQuartz]

@tdipisa this bug is caused by the linked resources associated with this map. The GetLegendGraphic requests is triggered by an embedded Legend in the map's details, but since the authkey is expired because it was persisted in the past, the request fails and the result is a broken image with an undefined alt text.

Also appears to reference other resources which may no longer exist on the server, hence the later requests and their 404 responses.

My investigations show that this may not be an actual bug but a result of obsolete data associated with this map, persisted by the backend.
Currently this issue may apply to resources which meet similar conditions as this.

[tdipisa]

@DavidQuartz thank you, I understand. In that case it is not a bug, I agree. Anyway, can you please let me know about the one below?

Also appears to reference other resources which may no longer exist on the server, hence the later requests and their 404 responses.

Which are the other resources involved for this map? The idea for this ticket is to also understand if there is a bug where certain resources are not properly removed when deleted: things like that. As you have mentioned also above, I imagine that probably for other maps we don't have this requests returning HTTP code 404.

[offtherailz]

I sync with David and, thanks to his investigation results I have found the following:

On every save (from map viewer or the home page), the home page interceptors listen for a change in order to update the result list. (We can optimize it to avoid in certain circumstances, for instance inside the map, but it will happen anyway if you save the resource attributes from the home page).

The undesired requests are caused by the system that handles the maps saved within contexts. For each map of this kind, the home page need to load also the context attributes (not the body) in order to:

• Guess if the context still exists and it is accessible for the user (otherwise it will use the default context).
• Get the "contextName", needed to generate the link for the user, when he clicks on the map. (the path is /context/{contextName}/{mapId})

The request failures are due to some maps that has been saved with a context, but later the context has been deleted.
To avoid this, we proposed some solution with this issue but maybe we can design something different at nowdays.

So apparently this is not a bug itself, but a the consequence of a known issue. So for me the issue can be closed. We can remove the maps or recreate them if needed. (please @DavidQuartz report the maps that have this problem).

About the re-design of #5149 I suggest to replace the "create map within a context", instead associating the map to a default context.
This has the advantage of being :

• Editable
• Easier to understand
• Somehow from the UI we can allow to open the map in another context, to make the editing of the map easier)

[DavidQuartz]

@tdipisa @offtherailz the maps current having this problem are this map and this map

[offtherailz]

I deleted them because they was both made to live within a context. the contexs has been removed, so no need for them anymore.

[offtherailz]

Closed in favor of #7917 and #5149