SAP CAP User

[Cristian]

Hi experts,

We have an entity as follows:

@assert.unique: {
  favourite: [user, useCasePatternInstance]
}
@description : 'User favourites reference architectures'
entity useCasePatternInstancesFavourites : managed, cuid {

    @mandatory user: String(200)
    @description: 'Application user';

    @mandatory useCasePatternInstance: Association to UseCasePatternInstances
    @description: 'Favoured use case pattern instance';

}

Where user is the user logged in the app consuming the ODATA service.

Instead of passing the user in the URL (for READ operations) or in the payload (for WRITE operations), is there any elegant to manage this with any kind of annotation where those details are retrieved automatically from the JWT token?

Many thanks!

C.

[david_kunz2]

Hi Mateo,

I'm not entirely sure what you want to achieve. Your fields are database fields which must be filled by you.
We support e.g. @cds.on.update:$user to fill it automatically.
https://cap.cloud.sap/docs/guides/domain-models#using-predefined-named-aspects

You can also have a look at restrict annotations: https://cap.cloud.sap/docs/guides/authorization#restrict-annotation
Maybe that is something you want to do.

Best regards,
David

[Cristian]

Many thanks david.kunz2

I have added the annotations for insert and update as follows:

@assert.unique: {
  favourite: [user, useCasePatternInstance]
}
@description : 'User favourites reference architectures'
entity useCasePatternInstancesFavourites : managed, cuid {

    @mandatory user: String(200) 
    @cds.on.insert : $user @cds.on.update : $user
    @description: 'Application user';

    @mandatory useCasePatternInstance: Association to UseCasePatternInstances
    @description: 'Favoured use case pattern instance';

}

But when executing the calls I am getting the error as follows:

{
    "error": {
        "code": "400",
        "message": "Value is required",
        "target": "user",
        "@Common.numericSeverity": 4
    }
}

The service is assigned to a custom role with @requires annotation and the retrieval of the token and further consumption of the service is working fine.

Any idea what may be going on?

Regards,

C.

[kammaje_cis]

@int_suite_test57, May be you should get rid of @mandatory for the 'user' since it is automatically updated with @cds.on.insert.

[david_kunz2]

Exactly, @mandatory is used for external input validation.

[Cristian]

Many thanks both david.kunz2 and kkammaje_cis

That sorted the issue. Now last question, how can I ensure that when a user makes a request to get the favourites as follows:

GET /useCasePatternInstancesFavourites

The API just responds with the entries where user = $user. Is there any way to do that with annotations or needs to be done programmatically in a handler?

Thanks!

C.

[david_kunz2]

Hi Mateo,

I'm not sure how you model favorites in terms of user properties, or what you exactly want to achieve. Could you clarify?

Best regards,

David

[Cristian]

david.kunz2,

Many thanks for your response.

We have an entity name useCasePatternInstances and the useCasePatternInstancesFavourites detailed above. At UI level, users can add to favourites several useCasePatternInstances, hence the relationship.

Then, users can see all their favourites and for that a GET request needs to be triggered. It is there when we want to ensure that the API just replies favourites for the user logged in. ODATA wise is very easy with the below request (user = email account):

GET /useCasePatternInstances?$filter=user eq '[email protected]'

But we want to avoid this and instead or hardcoding this in the URL we are exploring using annotations where this information is retrieved from the JWT token as it is happening in the insert and update operations with the cds annotations. This as well will reduce risks of users seen favourites of other users due to the fact that if you are clever enough you can execute F12 and in Google Tools you change the email of the request :).

Hope it is clear.

Regards,

M.

[david_kunz2]

Hi Mateo,

This is a typical use case for restrict annotations: https://cap.cloud.sap/docs/guides/authorization#restrict-annotation

Best regards,

David

[kammaje_cis]

As David mentioned. restrict annotation is one way. Another way can be to build it into the entity definition of the service itself.

At the time of defining the entity for the service, you can just do

Entity useCasePatternInstances as projection from <database table> where user = $user