[Share plugin - Permalink] Add a permalink functionality

[catmorales]

Description

'Permalink shares current user session (custom layers in the TOC, custom background layers, all user customizations) and not only the initial map of the Context. It should be public by default.
If some layers in it are protected by a geoserver rule, the layer will be ommited from the permalink, the functionnality should advice the user of it.
Permalink is necessary to complete the "share" plugin. His behaviour should be similar as Mapfishapp's permalink.

The Mapstore2 "share " plugin shares only the original context not the current context customized by user.
Now, to share the current session customized by himself, the user must:

• saves his map context (save plugin)
• affects good rights on it (everyone if he wants to share it with everyone)
• share the saved map context with the bounding box

For those which are not using the Save plugin (as Rennes Metropole), there is no alternative to share maps.

Other useful information

Eg in mapfishapp:

https://portail-test.sig.rennesmetropole.fr/mapfishapp/map/e0b1f5e9e8e14fb3d2b00446f61a7cac

Note

Related MS issue geosolutions-it/MapStore2#9250

[landryb]

wrt rights, two aspects:

• a platform admin should be able to decide if anonymous users are allowed to create permalinks (at share plugin configuration level) - with that we get the old mfapp behaviour back
• an user creating a permalink should have a checkbox to decide if the permalink is public (eg viewable by anonymous users) otherwise by default only connected users can access the permalink (and for others, behaviour from Better handle of context access restriction #415 should apply)

@MaelREBOUX @jusabatier - do you agree with that ?

poke @fphg :)

[tdipisa]

otherwise by default only connected users can access the permalink

That specific point is not possible according to the MS model (a resource created by an user is visible by default to the user himself and the admins, proper permission rules need otherwise to be set for groups the user belongs to). We can try to foresee a possible solution to propose for this.

[landryb]

otherwise by default only connected users can access the permalink

That specific point is not possible according to the MS model (a resource created by an user is visible by default to the user himself and the admins, proper permission rules need otherwise to be set for groups the user belongs to). We can try to foresee a possible solution to propose for this.

this particular default behaviour was also discussed in #274. A platform admin might want maps/contexts to be visible by anyone by default...

[catmorales]

A platform admin might want maps/contexts to be visible by anyone by default...

Yes I agree, it is the aim of the permalink, and one of the distinction I see with Share plugin. By default a permalink must be public (visible by everyone).

[tdipisa]

@landryb @catmorales

I'm sorry but I think we are not understanding each other on this point. Let me better explain the meaning of my comment above:

a platform admin should be able to decide if anonymous users are allowed to create permalinks (at share plugin configuration level) - with that we get the old mfapp behaviour back

ok, it should be possible but we have to check.

an user creating a permalink should have a checkbox to decide if the permalink is public (eg viewable by anonymous users)

ok

otherwise by default only connected users can access the permalink

Is that specific point that is not possible according to the current MS model as I've explained above. If not public, a resource is visible only to the user who created it or the admins otherwise a specific permission need to be configured for groups

Therefore, if your main goal is to make the user able to decide if a permalink must public or not, it is not a problem.

[catmorales]

Therefore, if your main goal is to make the user able to decide if a permalink must public or not, it is not a problem.

So I think it's OK. @landryb ?

[tdipisa]

@catmorales I will provide a most complete feedback later today as as result of our check as promised yesterday in the call so that you can better evaluate ,the overall implementation we are proposing.

[tdipisa]

@catmorales @landryb and all. We have checked again the task according to our yesterday's exchanges. I'm going to summarize below the overall task and what is possible to do within our evaluation.

'Permalink shares current user session (custom layers in the TOC, custom background layers, all user customizations) and not only the initial map of the Context. It should be public by default.

It is off course included. As I've already explained, the permalink support can allow to generate a new resource as the other ones DB side in a dedicated category named PERMALINK. The permalink has its own ID, as usual, to be used as a query param in the URL to load it. The same logic will be applied to contexts and maps created from a context.
Proper eviction policies of old permalinks from DB is not part of the task and it should be implemented on the DB side by the sys admin (with a trigger or similar for which we can also provide a sample to put in our documentation)

If some layers in it are protected by a geoserver rule, the layer will be ommited from the permalink, the functionnality should advice the user of it.

This will be handled as usual. No effort on our side since protected layers that are not visible to a certain user are already marked in TOC.

Permalink is necessary to complete the "share" plugin.

Yes, we will update the share plugin most probably for this but it is more a matter of design.

As promised yesterday, we have spent a few more time today to evaluate the additional points you mentioned in the call and then reported in comments above by @landryb.

a platform admin should be able to decide if anonymous users are allowed to create permalinks (at share plugin configuration level) - with that we get the old mfapp behaviour back

In theory it is technically possible but it is not recommended because this behavior is prone to security issues. This part was not included in our proposal indeed and this would require a dedicated evaluation and estimate:

• According to the current MS model you must be autenticated to create resources therefore the MS model and services should be updated for this and protected somehow
• Even if you decide to enable or not this function in the front-end doing nothing on the backend the REST API will be anyway open and prone to attacks. Therefore a solution to prevent this should be properly handled

As I wrote above it should be evaluated separately but, at a first glance, it seems to be something that changes too much the MS model and security policies to finally land in the MS core.

an user creating a permalink should have a checkbox to decide if the permalink is public (eg viewable by anonymous users)

This is possible according to the model and we can include it in our task without changing our estimate.

otherwise by default only connected users can access the permalink

This is not possible with the current MS model as I've explained above. The only solution we can foresee without changing too much our estimate is the possibility to have a dedicated role in geOrchestra to which all users belong (maybe it already exists?) and use it for the purpose by configuration in the same way of the "everyone" setting (point above).

His behaviour should be similar as Mapfishapp's permalink.

Well, I've checked it of course but let me know if I've missed something on the above for which we should reconsider again our evaluation. I've effectively explained what we can do in MS to provide this functionality. Let me know if it covers well what you need.

[landryb]

We're perfectly aware of the fact that a database can be "stuffed" with data if an anonymous user can create permalinks, but that's also what made mfapp/georchestra popular for some platforms. Hence the choice should be left to the platform admin to enable that or not (defaulting to false).

• According to the current MS model you must be autenticated to create resources therefore the MS model and services should be updated for this and protected somehow

• Even if you decide to enable or not this function in the front-end doing nothing on the backend the REST API will be anyway open and prone to attacks. Therefore a solution to prevent this should be properly handled

well, if there's a global toggle for the backend in /etc/georchestra, then the REST backend can be "secured" if the feature is kept disabled.

Anyway, you've made it clear that it wasn't included in the current estimate, so be it. It's a pity :)

[PLaot]

Problem with permalink generated from an old context #656