ouranosinc/magpie

AuthN/AuthZ services

Magpie: A RestFul AuthN/AuthZ service

Magpie (the smart-bird)

a very smart bird who knows everything about you.

Magpie is service for AuthN/AuthZ accessible via a REST API implemented with the Pyramid web framework. It allows you to manage User/Group/Service/Resource/Permission with a PostgreSQL database. Behind the scene, it uses Ziggurat-Foundations and Authomatic.

dependencies
tests status
docker status
releases

Documentation

The REST API documentation is auto-generated and served under {MAGPIE_URL}/api/ using Swagger-UI with tag latest.

More ample details about installation, configuration and usage are provided on ReadTheDocs_.
These are generated from corresponding information provided in docs_ directory.

Configuration and Usage

Multiple configuration options exist for Magpie application.
Please refer to Configuration_ section for details.
See Usage_ section for details.

Change History

Addressed features, changes and bug fixes per version tag are available in CHANGES_.

Docker Images

Following most recent variants are available:

Magpie	Twitcher (with integrated MagpieAdapter)
pavics/magpie:4.0.0	pavics/twitcher:magpie-4.0.0
pavics/magpie:latest	pavics/twitcher:magpie-latest

Notes:

• Older tags the are also available: Magpie Docker Images
• Twitcher image with integrated MagpieAdapter are only available for Magpie >=1.0.0

magpie's Issues

Duplicate permissions returned on User & Group corresponding permissions

When a user is part of a group and both the user and the group have a corresponding permission set, these permissions are duplicated in the returned list.

Happens for routes where a merge of permissions is done:

• {host}/magpie/users/{user_name}/resources
• {host}/magpie/users/{user_name}/resources/{resource_id}/permissions
• {host}/magpie/users/{user_name}/services
• {host}/magpie/users/{user_name}/services/{service_name}/permissions
• {host}/magpie/users/{user_name}/services/{service_name}/resources

Investigate duplicate resource names

The problem happened on hirondelle... While the code doesn't seem to allow for duplicates in resource names, there are a lot of duplicates in project-api on hirondelle. I also removes 2 out of 3 identical geoserver-api services. Not sure if the problem comes from a past version or if it's ongoing...

@fmigneault any thoughts?

This screenshot shows resources of project-api.

Services page should also display sync status

Contrarily to "Users/Services" and "Groups/Services" edit pages, the plain "Services" edit page doesn't indicate the last remote sync status + pending syncs on individual resources.

Even though resources that implement such sync mechanism won't need to be edited manually, it would be necessary to display the sync status nonetheless.

Reasons:

• both "Users/Services" and "Groups/Services" pages redirect to "Services" using the Edit Service button, so it doesn't make sense to "lose" information between corresponding resources trees.
• when editing services that require manual editing (no remote sync implemented) from the "Services" page, it is useful to know right away which ones implement or not the sync, and when it was last done (avoid many back and forth between pages)

Route DELETE all service sub-resources

Add installation instructions to README

Add label to resources in magpie

For some services, resources could be numerical with no context (project-api is a good example).
For them we could assign to the resource a friendly name that would be shown in the magpie UI.

Since the friendly name could be changed on the remote server it should only be store on the remote resource table which is update periodically and use for display only. Thus I see no needs to update the API or the main resources and permissions tables.

Project Workspaces Support in Magpie

Full Details: here

• Workspace permissions under Project thredds service (read, write)

• maybe more granular perms:
  CRUD Workflow (4) / CRUD dataset (4) / CRUD workflow (4) / CRUD search criterias (4) / CRUD jobs (4) => 20 + CRUD project => 24 permissions

• New routes:

  • GET {host_bird}/magpie/services/project
    details about project service
  • GET {host_bird}/magpie/services/project/permissions
    possible permissions (read, write, ...)
  • GET {host_bird}/magpie/services/project/resources
    list of registered projects
  • GET {host_bird}/magpie/services/project/resources/{id}
    details of specific project
  • GET {host_bird}/magpie/services/project/resources/{id}/permissions
    specific project permissions
  • GET {host_bird}/magpie/services/project/resources/{id}/user/{id}/permissions
    user project permissions (grant other user access to their project and such)
  • POST {host_bird}/magpie/services/project/resources/{name}
    create project
  • PUT {host_bird}/magpie/services/project/resources/{id}/permissions
    update project permissions

• Permissions:

  • read
  • write
  • (?)

Verify Magpie Signout procedure

It seems the Magpie signout is not invaliding properly the logged in user.

This doc: ziggurat-foundations seem to suggest the header must be passed to the HTTPOk response. But it doesn't seem to be the case currently:

Magpie/magpie/login/login.py

Line 122 in 40d5741

return valid_http(httpSuccess=HTTPOk, detail="Sign out successful")

References issue pavics-sdi #33

Magpie migration to 0.7.0

When migrating to 0.7.0, the resource_display_name is added.

For existing resources in the resources table that don't have an empty resource_display_name field, the resource_name is displayed. We should display the one from the remote_resources table when this happens It's not a big change, the comparison is already made to check if the resource exists on the remote server.

We could persist this resource_display_name in the resources table in another migration, but I think it's a bit overkill.

Make tests for Adapter

Minimal unittests for MagpieAdapter and related stores.

Generic Service for Route/Provider Access

TODO

• All services registered under the new service type with different server routes similarly to WPS (flyingpigeon, malleefowl, etc.)
• Services access validated per user permission
• Services registered under providers automatically (ref issue #58)

Reason

• Allow registering PAVICS-frontend, geoserver/web, Magpie or any other top-level route
• Needed to fully move routes behind Twitcher

Use Cornice validators for input body and header mandatory parameters

see for refenrece : https://github.com/Cornices/cornice.ext.swagger/blob/master/docs/source/tutorial.rst

Display alert error with invalid object names as 'functions'

When the name of the service as a invalid character for a function name (ex: with -), the display alert call fails on 'delete' button press because the function is undefined.

todo

• fix the behaviour by escaping the invalid characters
• add UI unittest to submit form on delete and inspect that popup appears (ref #74)

Geoserver API

TODO:

• permissions check accept requests (Geoserver Requests)
• permissions block other requests
• permissions read/write for resources (Geoserver Workspaces)
• add to service_type_dict for reference

Fix Login (for tests and in general)

Tests run locally fail because they cannot succeed the login procedure.

todo

• fix login procedure when using webtest.TestApp
• enable for travis (ref #140, commit 172bd0d)

error detail

. . . 
Starting Magpie app...
.......E....ssssssssssss
======================================================================
ERROR: setUpClass (tests.test_magpie_api.TestMagpieAPI_AdminAuth_Local)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/francis/VISI/PAVICS/magpie/tests/test_magpie_api.py", line 80, in setUpClass
    cls.check_requirements()
  File "/home/francis/VISI/PAVICS/magpie/tests/interfaces.py", line 113, in check_requirements
    assert cls.headers and cls.cookies, cls.require
AssertionError: cannot run tests without logged in 'administrators' user

======================================================================
ERROR: setUpClass (tests.test_magpie_ui.TestMagpieUI_AdminAuth_Local)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/francis/VISI/PAVICS/magpie/tests/test_magpie_ui.py", line 67, in setUpClass
    cls.headers, cls.cookies = utils.check_or_try_login_user(cls.url, cls.usr, cls.pwd, use_ui_form_submit=True)
  File "/home/francis/VISI/PAVICS/magpie/tests/utils.py", line 142, in check_or_try_login_user
    resp = app_or_url.get(url='/ui/login')
  File "/home/francis/.conda/envs/magpie/lib/python2.7/site-packages/webtest/app.py", line 331, in get
    expect_errors=expect_errors)
  File "/home/francis/.conda/envs/magpie/lib/python2.7/site-packages/webtest/app.py", line 651, in do_request
    self._check_status(status, res)
  File "/home/francis/.conda/envs/magpie/lib/python2.7/site-packages/webtest/app.py", line 683, in _check_status
    res)
AppError: Bad response: 500 Internal Server Error (not 200 OK or 3xx redirect for http://localhost/ui/login)
{"code": 500, "route_name": "/ui/login", "detail": "Internal Server Error. Unhandled exception occurred.", "request_url": "http://localhost/ui/login", "type": "application/json", "method": "GET"}

======================================================================
ERROR: test_Login (tests.test_magpie_ui.TestMagpieUI_NoAuth_Local)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/francis/VISI/PAVICS/magpie/tests/interfaces.py", line 731, in test_Login
  File "/home/francis/VISI/PAVICS/magpie/tests/utils.py", line 369, in check_UpStatus
    resp = test_request(test_class.url, method, path, cookies=test_class.cookies)
  File "/home/francis/VISI/PAVICS/magpie/tests/utils.py", line 90, in test_request
    return app_or_url.get(path, **kwargs)
  File "/home/francis/.conda/envs/magpie/lib/python2.7/site-packages/webtest/app.py", line 331, in get
    expect_errors=expect_errors)
  File "/home/francis/.conda/envs/magpie/lib/python2.7/site-packages/webtest/app.py", line 651, in do_request
    self._check_status(status, res)
  File "/home/francis/.conda/envs/magpie/lib/python2.7/site-packages/webtest/app.py", line 683, in _check_status
    res)
AppError: Bad response: 500 Internal Server Error (not 200 OK or 3xx redirect for http://localhost/ui/login)
{"code": 500, "route_name": "/ui/login", "detail": "Internal Server Error. Unhandled exception occurred.", "request_url": "http://localhost/ui/login", "type": "application/json", "method": "GET"}

----------------------------------------------------------------------
Ran 75 tests in 2291.536s

FAILED (errors=3, skipped=60)

Unittests

Check/validate functionalities added/adjusted in following cases:

• PR #72 (default users, groups and services properly registered after start)
• PR #73 (/services routes with permission_names listing applicable permissions)
• cover most critical routes used by PAVICS frontend
• /users routes
• /groups routes
• /resources routes
• /services routes
• inputs validation (see #84)
• new features from PR #104
• new features from PR #109
• test that validates #158 (do for both delete/create functions)
• tests for inherit query flag on all applicable routes
• tests for cascade query flag on all applicable routes
• tests for effective query flag on all applicable routes (PR #135)
• tests for register operations
• tests for CLI helpers (relates to PR #339)
• tests for MagpieAdapter (some introduced by PR #353, but not everything is covered)
  tests of basic functionality of MagpieAdapter for Twitcher (see issue #130)

Fetch Existing Service Resources to Populate Magpie Permissions

details

Potential services to fetch:

• geoserver 'workspaces' (projects, see #39)
• thredds (datasets, see #41)
• ...

Questions to consider :

• should Magpie 'automatically' trigger fetches (risk of removing perms if service is removed somewhere at the wrong moment)
• should Magpie UI have a button to trigger a fetch (force)
• ...

Full Details: here

planning

todo

• warning flag on non-existing resource between db & actual service (on each tree-line)
• update flags on user (with admin perms) goto page of service to fetch
• ask remove all warnings or cancel for user to remove resources one by one
• button to re-send the remove all warnings command (if any)
• if no permission is associated with a dangling resource, delete it immediately (no confirm required)
• if permissions are associated to a dangling resource, require user confirmation

configs all over the place

Multiple configs (ENV variables, settings, etc.) are either hardcoded in various locations, or default values in case of getenv calls fail are defined across multiple files, which makes it hard to track which ones are really used.

All configs should be defined in magpie.env file and loaded from there, unless already defined in the host machine.

Dockerfile should also retrieve these env variables unless already defined. (some are defined directly in the script currently [at least until 9e25c04])
Maybe also remove ENV specific to pavics ? Replace by default values (eg: localhost and such)?

Default Signin Provider not Required

• make 'ziggurat' not required for POST signin via API

Is the unique constraint on user's email necessary?

Currently, Magpie does not allow to have two user with different username but same email. Therefore, if you have local account and an openid account registered with the same email address, it won't work.

Associate external provider to logged user

Using the authomatic login procedure with external identity providers (github, wso2, dkrz, ...), instead of creating a new internal user, connect the external user to an already logged in user.

This allows an internal user to login with any of is associated accounts (similar to most sites using 'connect with Google/Facebook/etc.'), and combine all user permissions of a "same person" under a common internal user identity (no duplication required across each sub-user for each external provider).

ExternalIdentity already resolves properly to the internal user when logging in with an external identity if the associated db external_identities.local_user_id points to a valid internal user. Only the method to set this field needs to be implemented.

TODO

• Will require a new API route POST /providers/{providerId}/add to launch the
  GET /providers/{providerId}/signin procedure. On valid external login, it should create the external identity and associate it to the current user.

• API HTTPNotAuthorized on calling the new route if not logged in (with internal user).
  [using default magpie view permission should do it]

• API HTTPNotAuthorized on external login failure.

• API HTTPCreated on successful external identity creation and association to local user.

• Ensure that previous operations still work. If login is done with either:
  POST /signin {"provider_name": "<providerID>"}
GET /providers/{providerId}/signin
  without being logged in (internal user)

• Will require a new UI button to associate the new external provider, ideas:

  • "Link Account" button under "Log Out" (none when "Log In") redirecting to a "select provider" page?
  • row of icons of each provider, calling directly to proper POST /providers/{providerId}/add?

• Require DELETE /providers/{providerId} to dissociate an account connection, removing the ExternalIdentity that was created for it (does not remove the User associated to it).

• Add a UI button for running the dissociate operation.

Extra

• Improve the mechanism to auto-create the user on external provider login. Currently, the username is auto-generated using the provided username (on the external provider), which can rapidly lead to conflicts locally. An input field should be made available for the local username to employ, regardless of the value used as external identity.

Continuous Integration

• Travis-CI (https://travis-ci.com/Ouranosinc/Magpie)
• Implement CI pipeline with releases to docker hub (https://hub.docker.com/r/pavics/magpie)
• Run unittests on PR, tags, etc. (ref #74, #120, #130)

Swagger Improvements

• Magpie /api route displays UNDOCUMENTED RESPONSE in the swagger. It should display something like Swagger-UI of Magpie (this page).
• Ensure that code status values and description examples are properly created to corresponding responses.
• [ ] Magpie common servers could be rendered to enable testing
  (see https://swagger.io/docs/specification/api-host-and-base-path/)
  not relevant anymore with all server variants using magpie

ESGF x509 certificates

As referenced here: bird-house/birdy#105

Just a quick question to see how / if Magpie could be used to fetch the certificates, and how that could be used for our uses cases.

ServiceAccess problematic issues

References PR #75

test and concerns

(colibri)

• Service [geoserver-web]
  with https://colibri.crim.ca/twitcher/ows/proxy/geoserver-web
  ==> http://colibri.crim.ca:8087/geoserver

  • geoserver/web/ is properly protected by ServiceAccess because /web is after the corresponding geoserver-web permissions, but this also indirectly opens access to geoserver/rest/ (correspoding to geoserver-api service)
    this makes all geoserver-api permissions invalidated via this route !
  • if specifying instead :
    proxy https://colibri.crim.ca/twitcher/ows/proxy/geoserver-web
    ==> http://colibri.crim.ca:8087/geoserver/web,
    it is possible to avoid the above issue, but the page rendering is bad (because of missing root definitions at /geoserver level

• Service [frontend]
  with https://colibri.crim.ca/twitcher/ows/proxy/frontend
  ==> https://colibri.crim.ca OR http://colibri.crim.ca:443

  • UI simply doesn't display properly (black screen) due to failing underlying scripts

• Service [magpie]
  with https://colibri.crim.ca/twitcher/ows/proxy/magpie
  ==> http://colibri.crim.ca/magpie:2001 or http://colibri.crim.ca/magpie:2001/magpie

  • UI doesn't display properly (no styles, but visible) + very slow response times
  • API works very well (ex: https://colibri.crim.ca/twitcher/ows/proxy/magpie/services
  • obviously will need blocking deletion of 'admin' access to this route (locked out otherwise)

Use sync-type for service resource fetch

Relates to #42 (fetch service resources) and PR #104

Regarding comments starting at (detail of problem / envisioned solution) :
#104 (comment)

This feature becomes BLOCKER for OGC.
/processes/{id} will need to be automatically updated with new processes so that read/write permissions be updated as required.

Will resolve any 'fetching' variations of common ServiceAPI type for geoserver-api, project-api and twitcher-api .

Add default permissions set to anonymous, user and admin groups

If one of these group needs to be created a default set of permission should be added.

• Anonymous :
  • thredds: no rights
  • ncwms: Allow GetCapabilities, Forbids other method
  • geoserverwms: Allow GetCapabilities, Forbids other method
  • wfs: Allow DescribeFeatureType and GetCapabilities, Forbids other methods
  • wps: Allow DescribeProcess and GetCapabilities, Execute forbidden
• User : (Anonymous rights +)
  • thredds: read on root and write on specific folder (TBD) ?
  • wps: Allow Execute
• Admin :
  • Allow magpie permissions management
  • No other rights (not intended to 'use' the platform)

Improve display of service permissions

Since they are now returned by the API, service permissions could get better list display in Magpie UI.

Creating a new user also creates a new group

Is this the desired behavior ?

Auto-Register Providers on Magpie Start

Run register_providers.py in main() to ensure providers.cfg services are loaded and registered in Magpie.

Make invalid credentials less informative

• No specific invalid user/password, just a single generic "invalid credentials".
• Display with banner.

As discussed in meeting: https://www.crim.ca/confluence/pages/viewpage.action?pageId=21761637

API requests with POST not accepting JSON format

- POST {{HOSTNAME}}/magpie/resources (create resource)

• POST https://{{HOSTNAME}}/magpie/signin

Cleanup Startup Logs and Init Checks

• Startup Dockerfile directly with gunicorn instead of supervisor (see PR #90)
• Log/raise db migration fail (magpie doesn't start if not resolved to latest version)
• flag old vs expected latest db version in log (dropped: doesn't had much value, just call alembic history to get same info)
• ensure that log are properly created, written in convenient location and has convivial readability
  (ok: easily available via docker-compose logs magpie since run with gunicorn - see PR #90)

Remove "Current" User Route

current is used to access the logged user (or anonymous otherwise)
https://{bird}/magpie/users/current

If a user was created with the same name, unexpected behavior could occur.

On the other hand, route https://{bird}/magpie/session provides the exact same functionality without the special current user. If no session is active (no user logged in) no user info is returned with "authenticated": false.

The current user route should simply be removed.

This will affect many Twitcher routes... example:

https://colibri.crim.ca/twitcher/ows/proxy/catalog/pywps?service=WPS&request=execute&version=1.0.0&identifier=pavicsearch&DataInputs=limit=10000;facets=*;type=Aggregate;distrib=true;constraints=project:ClimEx;

which seem to use current when proper permissions are obtained.

Improve the users/groups initialisation script

We should create automatically "service" users use by services to access magpie.
Exemple are the catalog who needs an access to crawl thredds or project-api which required access to get the projects available to a particular user.
I propose that an env file lists all required "service" users that would be read by magpie initialisation script and also used by the services requiring that type of access to avoid duplicate user/pw configuration.

On top of that, these users + the anononymous user and the default users and administrators groups should be made read-only and prevent any renaming, deletion or password update. (relates #164)

Installation bug

python setup.py install fails at line

from magpie.__meta__ import __version__, __author__, __email__

because magpie and its dependencies are not yet installed when first running it.

Traceback (most recent call last):
  File "setup.py", line 10, in <module>
    from magpie.__meta__ import __version__, __author__, __email__
  File "/home/david/src/Magpie/magpie/__init__.py", line 5, in <module>
    from api_except import *
  File "/home/david/src/Magpie/magpie/api_except.py", line 1, in <module>
    from pyramid.httpexceptions import *
ImportError: No module named pyramid.httpexceptions

Transfer Swagger REST API definitions from Static File to Auto-Gen in Code

resume work started in PR #67
use cornice_swagger decorators and methods to auto-generate swagger-ui definitions

todo

• /services
• /resources
• /users
• /groups
• /login
• /version

Informative error message on login failure

At the moment we get

{"reason": "not specified", "code": 401, "type": "application/json", "detail": "Login failure"}

I'd like to know whether it is because the user does not exist or the password is wrong, and eventually, an HTML page with a link to make a request to get an account or send a message to obtain the password.

Ensure inputs are trimmed (spaces, etc.)

A service on hirondelle was named "ogctb13 " (notice the ending space).
This was causing errors when trying to edit the service via API and UI.

found via unittest run :
http://ci.corpo.crim.ca:8081/view/PAVICS/job/PAVICS_magpie_test_hirondelle/41

Should refuse invalid inputs:

• spaces
• slashes (/ \)
• any other invalid characters that would break RESTful requests

Admin user gets removed from administrators in some cases

I'm leaving this issue mostly as a reminder to myself.

It happened to me 2 or 3 times. As I was editing the administrators group as a logged in admin, I got kicked out of the admins group for an unknown reason. The user is completely unassigned from the administrators.

I couldn't reproduce it quickly, but if it happens again I'll take a closer look.

Dataset Access + Validation Check

• Dataset specific permissions (should it be a new Dataset service?)

• Return 403 for forbidden access (forbidden must hide 404, don't let know if the dataset even exists)

• On 200 (perms OK), return 404 on Dataset NotFound (magpie actually checks for the dataset existance)

• New routes: (all under thredds)

  • GET {host_bird}/magpie/services/dataset
    details about dataset service
  • GET {host_bird}/magpie/services/dataset/resources
    list of registered datasets
  • GET {host_bird}/magpie/services/dataset/resources/{id}
    details of specific dataset
  • GET {host_bird}/magpie/services/dataset/resources/{id}/permissions
    dataset permissions
  • POST {host_bird}/magpie/services/dataset/resources/{id}
    create dataset
  • PUT {host_bird}/magpie/services/dataset/resources/{id}/permissions
    update dataset permissions

• Possible dataset parameters:

  • public
  • private
  • conditional (?) - must agree to terms and conditions to use

• Possible permissions :

  • read - dataset visible
  • write - dataset can be overwritten / update (?)
  • pending - allowed access but not yet 'acknowledged' conditions (?)
  • ???

Full Details: here
ref issue #36

Merge geoserver-api geoserverwms and wfs into a single service named geoserver

All current services are using workspaces as resources and shared the same instance as backend.
So it makes sense to merge them and append their permissions into a single block.
The request parser will need to first determine which type of access is requested (geoserver api, wms or wfs) and then call the existing code for the good service type.

Geoserver workspace

There is a desire at Ouranos to use Geoserver to store layers that are not directly related to the PAVICS platform (ie results from past projects). It could be done by creating a PAVICS-frontend workspace, and modifying the frontend to have it filter for only the shapefiles within this workspace. Another option is to set up an other independent GeoServer instance, but I'm concerned it would increase the maintenance load. Thoughts ?

Regroup API Signin Routes + Transfer UI conditions to API

TODO:

• make a single route /singin for any type (local ziggurat or external provider)
  (handling of external redirects to be done by UI)
• let the API do the provider type switch, not the UI
• update REST API docs in repo + swaggerhub

Checks:

• ensure that external signin providers work (redirect to their login page + logged in after)
• ensure that cookies are properly saved/cleared from sigin/signout via API & UI
• ensure JSON & form/data compatibility for /signin (ref #50)

References / track source:

• blame login change
• diff signin external

Extra:

• modify credentials message while editing UI (issue #59)

Separate personal groups from standard groups

magpie/ui/groups :

• Should not show personal groups (solve also the problem that personal group should not be deleted directly (they are when deleting a user)

magpie/ui/users/add :

• Combobox "user group" should not show personal groups

magpie/ui/users/username :

• Groups Membership should not show personal groups (solve also the problem that a user should not be able to remove its own personal group)
• A panel showing personal group permission as in magpie/ui/groups/username/default should be shown (this is a more intuitive way to edit "user" permission. The fact that in the background we handle this by using a personnal group doesn't need to be shown in the UI)

Project-API Permissions

references issue #39

OPEN access (project-api will validate token and permission with magpie for such routes

• GET /project-api/api/Projects/projectsByMagpieAccess*

WRITE access for root project-api resource:

• POST /project-api/api/Projects?*

READ access for a given project

• GET /project-api/api/Projects/PROJECT_ID/datasets
• GET /project-api/api/Projects/PROJECT_ID/jobs
• GET /project-api/api/Projects/PROJECT_ID/researchs
• GET /project-api/api/Projects/PROJECT_ID/workflows

WRITE access for a given project:

• PATCH/PUT /project-api/api/Projects/PROJECT_ID?*
• POST /project-api/api/Projects/PROJECT_ID/datasets
• PATCH/PUT/DELETE/project-api/api/Projects/PROJECT_ID/datasets/DATASET_ID
• POST /project-api/api/Projects/PROJECT_ID/jobs
• POST /project-api/api/Projects/PROJECT_ID/researchs
• DELETE/project-api/api/Projects/PROJECT_ID/researchs/RESEARCH_ID
• POST /project-api/api/Projects/PROJECT_ID/workflows
• PATCH/PUT/DELETE project-api/api/Projects/PROJECT_ID/workflows/WORKFLOW_ID?*
• POST /project-api/api/Projects/PROJECT_ID/shareToUser?*
• POST /project-api/api/Projects/PROJECT_ID/shareToGroup?*

BLOCKED access:
All others routes should be blocked, please consult http://hirondelle.crim.ca:3005/explorer/

Support for self-signed SSL Certificate missing 1 url in the adapter

Found in docker image pavics/twitcher:pavics-0.3.16 which includes magie-0.7.3.

How to reproduce:

• Use self-signed SSL certificate
• Apply patch to pavics/twitcher:pavics-0.3.16 docker to support self-sign SSL certificate

cd /opt/birdhouse/src/twitcher
curl https://github.com/Ouranosinc/twitcher/commit/b42e052.patch | patch -p1 -N

• Configure twitcher service to talk to magpie service using httpS in MAGPIE_URL environment variable
• Configure twitcher/custom.cfg to disable ssl certificate verification

[settings]
ows-proxy-ssl-verify = false

• Give anonymous group read access to all WPS services
• Hit this url https://YOUR_HOST/twitcher/ows/proxy/flyingpigeon/wps?service=WPS&version=1.0.0&request=GetCapabilities
• Should return something like

<wps:Capabilities xmlns:gml="http://www.opengis.net/gml" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:wps="http://www.opengis.net/wps/1.0.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" service="WPS" version="1.0.0" xml:lang="en-US" xsi:schemaLocation="http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsGetCapabilities_response.xsd" updateSequence="1">
  <ows:ServiceIdentification>
    <ows:Title>Flyingpigeon 1.1_dev</ows:Title>
    <ows:Abstract>Processes for climate data, indices and extreme events</ows:Abstract>
    <ows:Keywords>
      <ows:Keyword>PyWPS</ows:Keyword>
      <ows:Keyword>WPS</ows:Keyword>
      <ows:Keyword>OGC</ows:Keyword>
      <ows:Keyword>processing</ows:Keyword>
      <ows:Keyword>Birdhouse</ows:Keyword>
      <ows:Keyword>flyingpigeon</ows:Keyword>
      <ows:Type codeSpace="ISOTC211/19115">theme</ows:Type>
    </ows:Keywords>

• But got the following error because twitcher service is unable to talks to magpie service behind a self-signed SSL certificate

<?xml version="1.0" encoding="utf-8"?>
<ExceptionReport version="1.0.0"
    xmlns="http://www.opengis.net/ows/1.1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.opengis.net/ows/1.1 http://schemas.opengis.net/ows/1.1.0/owsExceptionReport.xsd">
    <Exception exceptionCode="NoApplicableCode" locator="NotAcceptable">
        <ExceptionText>Could not find service: HTTPSConnectionPool(host='lvu.ouranos.ca', port=443): Max retries exceeded with url: /magpie/services (Caused by SSLError(SSLError(&quot;bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)&quot;,),)).</ExceptionText>
    </Exception>
</ExceptionReport> 

Hide Service URL API responses

Routes like /users/{usr}/services and /groups/{grp}/services should hide the service_url (private) field.
Route /services (admin access only) will show the service_url.

`permission_names` not returned in most GET calls

A few examples where "permission_names": []

• {host_bird}/magpie/services/thredds
• {host_bird}/magpie/services/thredds/resources
• {host_bird}/magpie/services/types/wps

Returned list in each case should be the list of available permissions (read, write, getcapabilities, and so on)

Document "Current" User Route in Magpie REST API