Recommended order of checks at an endpoint

This commit is contained in:
Marko Milić 2019-02-08 13:29:12 +01:00 committed by GitHub
parent 213e6a718d
commit 337ce611dc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -71,6 +71,34 @@ When naming variables use strict camel case e.g. use myUrl not myURL. This is so
}
}
```
### Recommended order of checks at an endpoint
```scala
lazy val createProduct: OBPEndpoint = {
case "banks" :: BankId(bankId) :: "products" :: ProductCode(productCode) :: Nil JsonPut json -> _ => {
cc =>
for {
// 1. makes sure the user which attempts to use the endpoint is authorized
(Full(u), callContext) <- authorizeEndpoint(UserNotLoggedIn, cc)
// 2. makes sure the user which attempts to use the endpoint is allowed to consume it
_ <- NewStyle.function.hasAtLeastOneEntitlement(failMsg = createProductEntitlementsRequiredText)(bankId.value, u.userId, createProductEntitlements)
// 3. checks the endpoint constraints
(_, callContext) <- NewStyle.function.getBank(bankId, callContext)
failMsg = s"$InvalidJsonFormat The Json body should be the $PostPutProductJsonV310 "
...
```
Please note that that checks at an endpoint should be applied only in case an user is authorized and has privilege to consume the endpoint. Otherwise we can reveal sensitive data to the user. For instace if we reorder the checks in next way:
```scala
// 1. makes sure the user which attempts to use the endpoint is authorized
(Full(u), callContext) <- authorizeEndpoint(UserNotLoggedIn, cc)
// 3. checks the endpoint constraints
(_, callContext) <- NewStyle.function.getBank(bankId, callContext)
failMsg = s"$InvalidJsonFormat The Json body should be the $PostPutProductJsonV310 "
(Full(u), callContext) <- authorizeEndpoint(UserNotLoggedIn, cc)
// 2. makes sure the user which attempts to use the endpoint is allowed to consume it
_ <- NewStyle.function.hasAtLeastOneEntitlement(failMsg = createProductEntitlementsRequiredText)(bankId.value, u.userId, createProductEntitlements)
```
the user which cannot consume the endpoint still can check does some bank exist or not at that instance. It's not the issue if banks are public data at the instance but it wouldn't be the only business case all the time.
## Writing tests