Next version of remote control API

[akks]

Since we have started to change remote control functions r5872 r5845 r5837 , the version of Remote control API should be increased.

But before doing this, we may need to implement some minor remote control enhancements. I propose to discuss all of them here.

I was asked to add some functionality by CupIvan, author and maintainer of one of Russian validators ​http://osm.cupivan.ru but it needs discussion.

1. Allow "noconfirm" option to add_tags parameter - do not show confirmation dialog at all (+one more security permission ? )

2. Allow separate request to return JOSM version (to check supporting extra fuctionality). Do we want to allow getting some more JOSM info, like installed plugins ?

3. Allow to add changeset tags that indicate using the specific validator/web tool by remote request (changeset_tags parameter?) , related to #8149

-- From me:

4. Document, enchance and use zoom_mode parameter in all possible commands (see also #5669)

5. (most crazy) Support opening remote file with preferences ​http://josm.openstreetmap.de/wiki/Help/Preferences/ImportExport or execute configuration xml script sent in POST request if the user really agree with it. This could help to install plugins, specify imagery sources customize toolbars/styles/presets for team work.

But there is possible security issue - for now, arbitrary JS execution is allowed and JS has full access to Java API. The code checker may be added to restrict the configuration, maybe forbid JS execution more complex than ${a==2 && b==3}.

6. Add usage example to the reply on errors and empty parameter lists, #8228

We could implement the steps independently, when reaching an agreement which ones to add.

[stoecker]

I'm against 1, 2 and 5. These are things which should not be remotely controlled. Remote control is dangerous, it should not become a nightmare.

For 1: I could accept a similar feature, e.g. if we add something like "Don't show confirm request any more for this session".

[akks]

Replying to stoecker:

For 1: I could accept a similar feature, e.g. if we add something like "Don't show confirm request any more for this session".

Agree. If the parameter "noconfirm" is present, the checkbox "Do not ask again in this session" is shown in add_tags dialog. Standard add_tags will always need confirmation that can not be skipped, because users are lazy :)

[Hind]

For 2: IMHO, this isn't a good idea. It's better to return a list of supported remote queries.

[akks]

Replying to Hind:

For 2: IMHO, this isn't a good idea. It's better to return a list of supported remote queries.

Yes, this can be joined with 6 #8228 (plain text with all supported queries for browser and something like JSON for automatic checking).

[bastiK]

Replying to stoecker:

I'm against 1, 2 and 5. These are things which should not be remotely controlled. Remote control is dangerous, it should not become a nightmare.

+1

For 1: I could accept a similar feature, e.g. if we add something like "Don't show confirm request any more for this session".

It would increase the security, if we ask for confirmation again, when the host changes.

[akks]

So, 2 is clearly discarded (other - waiting for more opinions). Proposed replacement:

2a. "/features" request: returns list of all commands with their parameters as JSON, implement together with text answer generation #8228

[ {"request": "imagery", "description": "....." , "examples":["/imagery?title=...&type={wms|tms|html|bing|scanex} .... "], 
  "parameters": [ "url", "title", "name", "min_zoom", "max_zoom" ], "optionalParametersCount":"1" }
, ... ]

[Don-vip]

My votes:

1) ok with parameter + stoecker's suggestion (checkbox for current session) + bastiK's security check
2) ok for 2a
3) ok for the idea, but we need to fix #8149 first (not an easy task I think)
4) ok
5) no
6) I would prefer a static link to our wiki rather than static examples. The wiki can be edited by other users.

[skyper]

Replying to Don-vip:

My votes:

1) ok with parameter + stoecker's suggestion (checkbox for current session) + bastiK's security check
2) ok for 2a
3) ok for the idea, but we need to fix #8149 first (not an easy task I think)
4) ok
5) no
6) I would prefer a static link to our wiki rather than static examples. The wiki can be edited by other users.

+1

The wiki needs some update. From a user's point of few, remote control is rather poor documented only under Preferences.

[akks]

OK, I agree too.

1. Do we need noconfirm parameter? Or we just allow user to skip all dialogs in current session? About determining host - most of remote control actions come from localhost to localhost (we should of course be aware of real remote control, but this is not common usecase).

5. or similar - no arbitrary changes, OK. Do not we need some specific requests like imagery? Maybe adding plugins / styles / filters / presets?

[bastiK]

Replying to akks:

I agree too. Some additional qustions:

1. Do we need noconfirm parameter? Or we just allow user to skip all dialogs in current session?

Why not simply let the user decide?

About determining host - most of remote control actions come from localhost to localhost (we should of course be aware of real remote control, but this is not common usecase).

Ok, stupid idea. There is no way to determine the website, where the user clicked the remote-control link.

5. or similar - no arbitrary changes, OK :) Do not we need some specific requests like imagery? Maybe adding plugins / styles / filters / presets?

I agree, there is the need to add certain plugins, styles, presets and imagery all in one go e.g. for HOT teams. But I'd prefer to do it in another way. E.g. as an "extension package", which would essentially be a zip file with some meta-info.

[simon04]

Replying to bastiK:

About determining host - most of remote control actions come from localhost to localhost (we should of course be aware of real remote control, but this is not common usecase).

Ok, stupid idea. There is no way to determine the website, where the user clicked the remote-control link.

There is – evaluate the Referer HTTP header, e.g. Referer=​http://www.openstreetmap.org/ when clicking edit in JOSM on the main website.

ad 6: My hope is that usage examples are updated more frequently when they are contained in the source code, especially since the method getUsageExamples in #8228 has to be implemented for all handlers.

[akks]

Replying to simon04:

There is – evaluate the Referer HTTP header, e.g. Referer=​http://www.openstreetmap.org/ when clicking edit in JOSM on the main website.

Ok, this looks good. So, 1 is replaced with

1a. Checkbox "Do not ask again in this session for site ..." is shown in add_tags dialog. Site is determined by referrer header, if possible. Queries not from localhost always need confirmation are distinguished by IP.

ad 6: My hope is that usage examples are updated more frequently when they are contained in the source code, especially since the method getUsageExamples in #8228 has to be implemented for all handlers.

I agree. But the link to JOSM help is also useful. Let us have both?

[akks]

In 5876/josm:

Remote control: allow adding tags without confirmation for current session (add_tags), see #8612
added parsing of request headers and detecting request sender by IP and "referer" HTTP header

[akks]

Please check and improve if needed. Current status:

(1a) is implemented,
(3) waits for Don-vip's #8149,
(2a)+(6) (/features, examples) - simopn04 and I can implement based on patch #8228
(4) - I can implement it later, if someone wants - post message here
(5) - rejected (packs can be already created by opening downloaded custom configurator script XML)

[simon04]

Replying to akks:

ad 6: My hope is that usage examples are updated more frequently when they are contained in the source code, especially since the method getUsageExamples in #8228 has to be implemented for all handlers.

I agree. But the link to JOSM help is also useful. Let us have both?

No strong objections, but I slightly prefer only one place of documentation to avoid inconsistencies. This is what I did for the TaggingPresets documentation: referring the Wiki visitor to the corresponding source code.

[Don-vip]

Replying to akks:

In 5876/josm:

This change broke wikipedia plugin.

[Don-vip]

Replying to akks:

(3) waits for Don-vip's #8149,

I have no immediate plans to fix this particular ticket, I am not sure how to do it.

[akks]

Replying to Don-vip:

Replying to akks:

In 5876/josm:

This change broke wikipedia plugin.

Oops... Please fix it if you can, I am out of time until evening...

[akks]

I am fixing plugins.

[Don-vip]

The previous constructor without sender argument should be restored:

public AddTagsDialog(String[][] tags) { 
    this(tags, null);
}

[akks]

Fixed Wikipedia in [o29511] (sorry for unused import).

Maybe it is better to make constructor of AddTagsDialog private now and add extra static methods? static methods contain confirmation skipping logic while constructor does not...

public static void addTags(String[][] keyValue) {
    addTags(keyValue, ""); 
}

[akks]

Here is the patch with initial and unfinished support of "features" request and also with list of optional request parameters.
Usage examples and text from #8228 can be added too if all agree to store them in code (not only in Wiki).

This will go to new Latest, no Tested, I guess.

[akks]

In 6091/josm:

see #8612, #8228: remote control - add examples [patch by simon04, parts], add /feature request to detect commands

[akks]

Features JSON:
​http://localost:8011/features

Full list:
​http://localost:8011/asdfghj

Do we need something else before changing remote API version to 1.6?