APOLLO & ECW/JP2 Discussions

[haayman]

If I'm using the endpoint /content/catalog/items/{ID}/rights to give a certain user reader rights to an aggregate, I expect the getCapabilities to return that layer.

However: it turns out that that user also needs reader rights for every aggregate layer up in the hierarchy and all images within that aggregate.

Is it weird that I expect the API to handle this for me? Now I have to call the API potentially hundreds of times to add the rights for every individual image in the aggregate and a few more for the aggregates higher in the hierarchy.

The datamanager at least has the 'Apply To Children' option. It would be very useful to have that option available in the API. Also 'Apply to Parents'

[flo]

You can already access that aggregate by doing a "getLayer":

https://myApollo/erdas-apollo/ApolloCatalogWMS/service.svc/get?service=WMS&version=1.3.0&request=getLayer&layers=myLayer1

But right, if you request the full capabilities document, if the user hasn't the right to see the parent aggregate(s), he won't see the children.

You can still submit a new idea in the ideation board if you wish.

[haayman]

It turns out that even when I set the reader rights to all children and parents I still get a 403 when I try to access the getCapabilities of the WMS. I got this rather passive-aggressive error message:

The server understood the request but refuses to authorize it.

To recap:

• I've added a new principal: 'a_subscription_user'. This user has no roles
• selected an aggregate_item and called /content/catalog/items/{id}/rights on all it's children and parents with payload

[
  {
    "principal": "a_subscription_user",
    "reader": true,
    "deleter": false,
    "updater": false,
    "executer": false,
    "manager": false,
  }
]

When I check the datamanager everything seems to be correct. 'a_subscription_user' has access on all levels.

So what else needs to be done to call 

http://localhost/erdas-apollo/coverage/EAIM?SERVICE=wms&REQUEST=GetCapabilities

with the correct authentication headers set?

[flo · Accepted solution]

I could duplicate this behavior. Not sure if it is a WAD or a regression.

It looks like, to make it work, you need to work with roles and not users. You must create a new role (which is a alias of a system role) and assign this role to some aggregates. Then, give your user that role.

[haayman]

I just noticed something important. It's not the rights, but the principals that's going wrong.

Since there's no API for principals management I've added principals and user_roles directly into the database. Now I've discovered that I cannot login into the 'Catalog Web Interface' using those credentials.

To recap: using the Datamanager I've added a principal 'a_subscription_user' pw: 'a subscription user' and in the database there's an extra tuple with principal_type: 2, principal_id: 4028828a74b9badd01750cd78dd10da2, name: a_subscription_user, password: 'a subscription user' 

The user has no roles

I can use these credentials to login to the Catalog Web Interface

However, when I directly insert:

principal_type: 2, principal_id: 2geESaL9Gsso3iRoPZJ1gY, name: e476578a1bd08827611c, password: 9umhRdbfr

I cannot login

[haayman]

What do you mean with 'which is an alias of a system role'? I've created a new role and using the Datamanager I've given each layer read rights for that role. Still I get a 403

If I'd assign it as an aliased system role, wouldn't that be the same as assigning that system role directly to the user?