Revise the Proxy plugin

[jri]

It was a quick hack and has some flaws.

Its functionality is better realized via the OSGi HTTP service in conjunction with a custom HttpContext?.

[Jörg Richter]

Core: publishing a directory to the web (#292).

The Core's WebPublishingService? provides a new feature for publishing a directory of the server's file system to the web.
A plugin can do so by calling:

    publishDirectory(String directoryPath, String uriNamespace)

(This method is located in the plugin base class, PluginActivator?).
Unpublishing is automatic when the plugin shuts down.

This feature replaces that very feature of the Proxy plugin.
The remaining Proxy features are about to be transfered to the Files plugin and the Proxy plugin is about to be dropped.

The first plugin who uses this new feature is the Files plugin. It publishes its file repository to URI namespace /filerepo
The file repository is still be configured via the POM properties

    dm4.proxy.files.path
    dm4.proxy.net.filter

These are about to be renamed.

CAUTION: the Proxy plugin's security netfilter feature is not yet ported to the WebPublishingService?, so for the moment the "file-repo" branch opens a huge security hole. Do NOT install it!

See ticket 292.

• Changeset: dea0910b55f047483a37cf5d4d5716925d03f6ed
• URL: ​https://github.com/jri/deepamehta/commit/dea0910b55f047483a37cf5d4d5716925d03f6ed

[Jörg Richter]

Transfer Proxy features to Files plugin (#292).

The Proxy plugin and the /proxy URI namespace are obsolete.
The Proxy plugin is removed.
Its functionality is taken over by the Files plugin.
URI namespaces for the files API and the actual file repository are respectively:

    files/
    filerepo/

The 2 dm4.proxy... config properties are obsolete.
The new properties are:

    dm4.filerepo.path
    dm4.filerepo.netfilter

CAUTION: access to the file repository is not yet secured by the netfilter setting.
For single-user installations do NOT install the "file-repo" branch.
For multi-user installations make shure dm4.filerepo.path is set to a directory whose contents are supposed to be public.

See ticket 292.

• Changeset: 316398d361f18f36eac6eb5276260f4d3fc9d4d4
• URL: ​https://github.com/jri/deepamehta/commit/316398d361f18f36eac6eb5276260f4d3fc9d4d4

[Jörg Richter]

Files plugin: fix icons and map background (#292).

See ticket 292.

• Changeset: 883373271f5234e880b16526f11d6a95868db21f
• URL: ​https://github.com/jri/deepamehta/commit/883373271f5234e880b16526f11d6a95868db21f

[Jörg Richter]

Files plugin: fix getResourceInfo() call (#292).

See ticket 292.

• Changeset: 5021ca3d756bad6aa85a42d29fc637d371af3153
• URL: ​https://github.com/jri/deepamehta/commit/5021ca3d756bad6aa85a42d29fc637d371af3153

[Jörg Richter]

Files plugin: netfilter security (#292).

    dm4.filerepo.netfilter

This config property is respected.
Only clients belonging to the specified subnet have access to the file repository.

To restrict access to localhost:

    127.0.0.1/32

This is suitable for single-user installations.
This is the default.

To allow public access:

    127.0.0.1/0

See ticket 292.

• Changeset: 8c5b786c279d1414670f077689fbd617f8d64c81
• URL: ​https://github.com/jri/deepamehta/commit/8c5b786c279d1414670f077689fbd617f8d64c81

[Jörg Richter]

Files plugin: consolidate security (#292, #289).

Both, the Files API (/files URI) and the file respository (/filerepo URI) are consistently secured.
Each of the respective requests is secured by 2 measures:

• Subnet restriction: the request must originate from an allowed subnet (according to the dm4.filerepo.netfilter setting). Otherwise "403 Forbidden" is send back.
• Fighting directory traversal attacks: once canonicalized (resolving ../ references) the request's "path" parameter must point inside the file repository (according to the dm4.filerepo.path setting). Otherwise "403 Forbidden" is send back.

Furthermore, if the request's "path" parameter refers to a non-existing resource (file or directory)
"404 Not Found" is send back.

Additionally the upload mechanism is revised: the ID of the respective File topic is not included in the name of the stored file anymore. The original (client-side) file name is only changed if such a file already exists in the file repository. In this case a -2, -3, -4, ... suffix is added to the file's basename.

See ticket 292.
See ticket 289.

• Changeset: eba62cfb8f5b728bc4875a6cd6d4c190ac2e36e2
• URL: ​https://github.com/jri/deepamehta/commit/eba62cfb8f5b728bc4875a6cd6d4c190ac2e36e2

[Jörg Richter]

Files plugin: fix opening files and folders (#292)

... via doubleclick in their origin application.

The REST API is changed:

/files/open/<topicId>

topicId is the ID of a File or a Folder topic.

Note: opening files does not yet work in multi-user setup (that is client and server on different machines).

See ticket 292.

• Changeset: 26d6cc0fbd3409da71ca8a0dbc5313b18aa2e551
• URL: ​https://github.com/jri/deepamehta/commit/26d6cc0fbd3409da71ca8a0dbc5313b18aa2e551

[Jörg Richter]

Files plugin: create folder in file repo (#292).

GUI:
To create a folder in the file repository a Folder topic provides a "Create Folder" button.
The new folder is created inside the directory represented by that origin Folder topic.

API:
The Files OSGi service provides a new method:

    void createFolder(String folderName, String path)

"path" is relative to the file repo root dir.
It points to the directory where to create the new folder.
It must begin with "/".

Note:
for the moment creating repo folders is different from creating repo files (through upload) in 3 regards:
1) Creating a folder doesn't involve searching for a "free" name.

If such a folder already exists 500 Internal Server Error is returned.

2) Creating a folder doesn't automatically create a corresponding Folder topic.

The Folder topic is created on-the-fly when browsing the repo interactively.

3) Creating a folder returns no response entity, just 204 No Content.

See ticket 292.

• Changeset: 264c83a7e065fee90a862801744d50c6d6cc19e6
• URL: ​https://github.com/jri/deepamehta/commit/264c83a7e065fee90a862801744d50c6d6cc19e6

[Jörg Richter]

Core: publishing a directory to the web (#292).

The Core's WebPublishingService? provides a new feature for publishing a directory of the server's file system to the web.
A plugin can do so by calling:

    publishDirectory(String directoryPath, String uriNamespace)

(This method is located in the plugin base class, PluginActivator?).
Unpublishing is automatic when the plugin shuts down.

This feature replaces that very feature of the Proxy plugin.
The remaining Proxy features are about to be transfered to the Files plugin and the Proxy plugin is about to be dropped.

The first plugin who uses this new feature is the Files plugin. It publishes its file repository to URI namespace /filerepo
The file repository is still be configured via the POM properties

    dm4.proxy.files.path
    dm4.proxy.net.filter

These are about to be renamed.

CAUTION: the Proxy plugin's security netfilter feature is not yet ported to the WebPublishingService?, so for the moment the "file-repo" branch opens a huge security hole. Do NOT install it!

See ticket 292.

• Changeset: dea0910b55f047483a37cf5d4d5716925d03f6ed
• URL: ​https://github.com/jri/deepamehta/commit/dea0910b55f047483a37cf5d4d5716925d03f6ed

[Jörg Richter]

Transfer Proxy features to Files plugin (#292).

The Proxy plugin and the /proxy URI namespace are obsolete.
The Proxy plugin is removed.
Its functionality is taken over by the Files plugin.
URI namespaces for the files API and the actual file repository are respectively:

    files/
    filerepo/

The 2 dm4.proxy... config properties are obsolete.
The new properties are:

    dm4.filerepo.path
    dm4.filerepo.netfilter

CAUTION: access to the file repository is not yet secured by the netfilter setting.
For single-user installations do NOT install the "file-repo" branch.
For multi-user installations make shure dm4.filerepo.path is set to a directory whose contents are supposed to be public.

See ticket 292.

• Changeset: 316398d361f18f36eac6eb5276260f4d3fc9d4d4
• URL: ​https://github.com/jri/deepamehta/commit/316398d361f18f36eac6eb5276260f4d3fc9d4d4

[Jörg Richter]

Files plugin: fix icons and map background (#292).

See ticket 292.

• Changeset: 883373271f5234e880b16526f11d6a95868db21f
• URL: ​https://github.com/jri/deepamehta/commit/883373271f5234e880b16526f11d6a95868db21f

[Jörg Richter]

Files plugin: fix getResourceInfo() call (#292).

See ticket 292.

• Changeset: 5021ca3d756bad6aa85a42d29fc637d371af3153
• URL: ​https://github.com/jri/deepamehta/commit/5021ca3d756bad6aa85a42d29fc637d371af3153

[Jörg Richter]

Files plugin: netfilter security (#292).

    dm4.filerepo.netfilter

This config property is respected.
Only clients belonging to the specified subnet have access to the file repository.

To restrict access to localhost:

    127.0.0.1/32

This is suitable for single-user installations.
This is the default.

To allow public access:

    127.0.0.1/0

See ticket 292.

• Changeset: 8c5b786c279d1414670f077689fbd617f8d64c81
• URL: ​https://github.com/jri/deepamehta/commit/8c5b786c279d1414670f077689fbd617f8d64c81

[Jörg Richter]

Files plugin: consolidate security (#292, #289).

Both, the Files API (/files URI) and the file respository (/filerepo URI) are consistently secured.
Each of the respective requests is secured by 2 measures:

• Subnet restriction: the request must originate from an allowed subnet (according to the dm4.filerepo.netfilter setting). Otherwise "403 Forbidden" is send back.
• Fighting directory traversal attacks: once canonicalized (resolving ../ references) the request's "path" parameter must point inside the file repository (according to the dm4.filerepo.path setting). Otherwise "403 Forbidden" is send back.

Furthermore, if the request's "path" parameter refers to a non-existing resource (file or directory)
"404 Not Found" is send back.

Additionally the upload mechanism is revised: the ID of the respective File topic is not included in the name of the stored file anymore. The original (client-side) file name is only changed if such a file already exists in the file repository. In this case a -2, -3, -4, ... suffix is added to the file's basename.

See ticket 292.
See ticket 289.

• Changeset: eba62cfb8f5b728bc4875a6cd6d4c190ac2e36e2
• URL: ​https://github.com/jri/deepamehta/commit/eba62cfb8f5b728bc4875a6cd6d4c190ac2e36e2

[Jörg Richter]

Files plugin: fix opening files and folders (#292)

... via doubleclick in their origin application.

The REST API is changed:

/files/open/<topicId>

topicId is the ID of a File or a Folder topic.

Note: opening files does not yet work in multi-user setup (that is client and server on different machines).

See ticket 292.

• Changeset: 26d6cc0fbd3409da71ca8a0dbc5313b18aa2e551
• URL: ​https://github.com/jri/deepamehta/commit/26d6cc0fbd3409da71ca8a0dbc5313b18aa2e551

[Jörg Richter]

Files plugin: create folder in file repo (#292).

GUI:
To create a folder in the file repository a Folder topic provides a "Create Folder" button.
The new folder is created inside the directory represented by that origin Folder topic.

API:
The Files OSGi service provides a new method:

    void createFolder(String folderName, String path)

"path" is relative to the file repo root dir.
It points to the directory where to create the new folder.
It must begin with "/".

Note:
for the moment creating repo folders is different from creating repo files (through upload) in 3 regards:
1) Creating a folder doesn't involve searching for a "free" name.

If such a folder already exists 500 Internal Server Error is returned.

2) Creating a folder doesn't automatically create a corresponding Folder topic.

The Folder topic is created on-the-fly when browsing the repo interactively.

3) Creating a folder returns no response entity, just 204 No Content.

See ticket 292.

• Changeset: 264c83a7e065fee90a862801744d50c6d6cc19e6
• URL: ​https://github.com/jri/deepamehta/commit/264c83a7e065fee90a862801744d50c6d6cc19e6

[Jörg Richter]

Core: publishing a directory to the web (#292).

The Core's WebPublishingService? provides a new feature for publishing a directory of the server's file system to the web.
A plugin can do so by calling:

    publishDirectory(String directoryPath, String uriNamespace)

(This method is located in the plugin base class, PluginActivator?).
Unpublishing is automatic when the plugin shuts down.

This feature replaces that very feature of the Proxy plugin.
The remaining Proxy features are about to be transfered to the Files plugin and the Proxy plugin is about to be dropped.

The first plugin who uses this new feature is the Files plugin. It publishes its file repository to URI namespace /filerepo
The file repository is still be configured via the POM properties

    dm4.proxy.files.path
    dm4.proxy.net.filter

These are about to be renamed.

CAUTION: the Proxy plugin's security netfilter feature is not yet ported to the WebPublishingService?, so for the moment the "file-repo" branch opens a huge security hole. Do NOT install it!

See ticket 292.

• Changeset: dea0910b55f047483a37cf5d4d5716925d03f6ed
• URL: ​https://github.com/jri/deepamehta/commit/dea0910b55f047483a37cf5d4d5716925d03f6ed

[Jörg Richter]

Transfer Proxy features to Files plugin (#292).

The Proxy plugin and the /proxy URI namespace are obsolete.
The Proxy plugin is removed.
Its functionality is taken over by the Files plugin.
URI namespaces for the files API and the actual file repository are respectively:

    files/
    filerepo/

The 2 dm4.proxy... config properties are obsolete.
The new properties are:

    dm4.filerepo.path
    dm4.filerepo.netfilter

CAUTION: access to the file repository is not yet secured by the netfilter setting.
For single-user installations do NOT install the "file-repo" branch.
For multi-user installations make shure dm4.filerepo.path is set to a directory whose contents are supposed to be public.

See ticket 292.

• Changeset: 316398d361f18f36eac6eb5276260f4d3fc9d4d4
• URL: ​https://github.com/jri/deepamehta/commit/316398d361f18f36eac6eb5276260f4d3fc9d4d4

[Jörg Richter]

Files plugin: fix icons and map background (#292).

See ticket 292.

• Changeset: 883373271f5234e880b16526f11d6a95868db21f
• URL: ​https://github.com/jri/deepamehta/commit/883373271f5234e880b16526f11d6a95868db21f

[Jörg Richter]

Files plugin: fix getResourceInfo() call (#292).

See ticket 292.

• Changeset: 5021ca3d756bad6aa85a42d29fc637d371af3153
• URL: ​https://github.com/jri/deepamehta/commit/5021ca3d756bad6aa85a42d29fc637d371af3153

[Jörg Richter]

Files plugin: netfilter security (#292).

    dm4.filerepo.netfilter

This config property is respected.
Only clients belonging to the specified subnet have access to the file repository.

To restrict access to localhost:

    127.0.0.1/32

This is suitable for single-user installations.
This is the default.

To allow public access:

    127.0.0.1/0

See ticket 292.

• Changeset: 8c5b786c279d1414670f077689fbd617f8d64c81
• URL: ​https://github.com/jri/deepamehta/commit/8c5b786c279d1414670f077689fbd617f8d64c81

[Jörg Richter]

Files plugin: consolidate security (#292, #289).

Both, the Files API (/files URI) and the file respository (/filerepo URI) are consistently secured.
Each of the respective requests is secured by 2 measures:

• Subnet restriction: the request must originate from an allowed subnet (according to the dm4.filerepo.netfilter setting). Otherwise "403 Forbidden" is send back.
• Fighting directory traversal attacks: once canonicalized (resolving ../ references) the request's "path" parameter must point inside the file repository (according to the dm4.filerepo.path setting). Otherwise "403 Forbidden" is send back.

Furthermore, if the request's "path" parameter refers to a non-existing resource (file or directory)
"404 Not Found" is send back.

Additionally the upload mechanism is revised: the ID of the respective File topic is not included in the name of the stored file anymore. The original (client-side) file name is only changed if such a file already exists in the file repository. In this case a -2, -3, -4, ... suffix is added to the file's basename.

See ticket 292.
See ticket 289.

• Changeset: eba62cfb8f5b728bc4875a6cd6d4c190ac2e36e2
• URL: ​https://github.com/jri/deepamehta/commit/eba62cfb8f5b728bc4875a6cd6d4c190ac2e36e2

[Jörg Richter]

Files plugin: fix opening files and folders (#292)

... via doubleclick in their origin application.

The REST API is changed:

/files/open/<topicId>

topicId is the ID of a File or a Folder topic.

Note: opening files does not yet work in multi-user setup (that is client and server on different machines).

See ticket 292.

• Changeset: 26d6cc0fbd3409da71ca8a0dbc5313b18aa2e551
• URL: ​https://github.com/jri/deepamehta/commit/26d6cc0fbd3409da71ca8a0dbc5313b18aa2e551

[Jörg Richter]

Files plugin: create folder in file repo (#292).

GUI:
To create a folder in the file repository a Folder topic provides a "Create Folder" button.
The new folder is created inside the directory represented by that origin Folder topic.

API:
The Files OSGi service provides a new method:

    void createFolder(String folderName, String path)

"path" is relative to the file repo root dir.
It points to the directory where to create the new folder.
It must begin with "/".

Note:
for the moment creating repo folders is different from creating repo files (through upload) in 3 regards:
1) Creating a folder doesn't involve searching for a "free" name.

If such a folder already exists 500 Internal Server Error is returned.

2) Creating a folder doesn't automatically create a corresponding Folder topic.

The Folder topic is created on-the-fly when browsing the repo interactively.

3) Creating a folder returns no response entity, just 204 No Content.

See ticket 292.

• Changeset: 264c83a7e065fee90a862801744d50c6d6cc19e6
• URL: ​https://github.com/jri/deepamehta/commit/264c83a7e065fee90a862801744d50c6d6cc19e6

[Jörg Richter]

Files module: new service call getFile() (#292).

The Files service provides a new method:

    File getFile(long fileTopicId)

It provides 3rd party plugins access to the file repository via the Files OSGi service.

Note: this is not a REST resource method. To access a file remotely use the /filerepo resource.

See ticket 292.

• Changeset: 4ad366e22a16449130c4e9a0cb46bc46ca369b7e
• URL: ​https://github.com/jri/deepamehta/commit/4ad366e22a16449130c4e9a0cb46bc46ca369b7e

[Jörg Richter]

Files module: new service call getFile() (#292).

The Files service provides a new method:

    File getFile(long fileTopicId)

It provides 3rd party plugins access to the file repository via the Files OSGi service.

Note: this is not a REST resource method. To access a file remotely use the /filerepo resource.

See ticket 292.

• Changeset: 4ad366e22a16449130c4e9a0cb46bc46ca369b7e
• URL: ​https://github.com/jri/deepamehta/commit/4ad366e22a16449130c4e9a0cb46bc46ca369b7e