APOLLO & ECW/JP2 Discussions

Wondering how others have configured their ERDAS APOLLO server or what data they are crawling? The ERDAS APOLLO Discussion board is a place to find information, share ideas and more. Join the community, connect, contribute and share.
Showing results for 
Search instead for 
Do you mean 
Reply
Frequent Contributor
Posts: 130
Registered: ‎10-16-2015
Accepted Solution

setting the rights using the API doesn't function sufficiently for getCapabilities

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'

 

 

Moderator
Moderator
Posts: 385
Registered: ‎11-16-2015

Re: setting the rights using the API doesn't function sufficiently for getCapabilities

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.

Frequent Contributor
Posts: 130
Registered: ‎10-16-2015

Re: setting the rights using the API doesn't function sufficiently for getCapabilities

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?

Moderator
Moderator
Posts: 385
Registered: ‎11-16-2015

Re: setting the rights using the API doesn't function sufficiently for getCapabilities

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.

Frequent Contributor
Posts: 130
Registered: ‎10-16-2015

Re: setting the rights using the API doesn't function sufficiently for getCapabilities

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

 

 

Frequent Contributor
Posts: 130
Registered: ‎10-16-2015

Re: setting the rights using the API doesn't function sufficiently for getCapabilities

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?