@RestAddress Annotation Cancel

1. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   21 Jul 2020

   Link to this post

   When you add this annotation and set canUpdate="true" that will allow for the record to be updated via the REST call. Is there a way to prevent certain fields from being updated?
   
   @RestAddress (type="record", address="/TrainingCustomers/~{CustomerNum}", tables="eCustomer", id="CustomerNum",
                 fields="eCustomer.*", canRead="true", canUpdate="true", canDelete="true",
                 links="orders:/Customers/~{CustomerNum}/Orders").
2. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   22 Jul 2020 in reply to Roger Blanchard

   Link to this post

   Not through the annotations.
   
   You can restrict fields from being updated via authorization or validation.
3. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   22 Jul 2020 in reply to Mike Fechner

   Link to this post

   When you say "validation" our you referring to ValidataData in the BE? If so how can you determine the update is coming from REST (WebHandler) versus a GUI front end? Otherwise we would have to have a separate BE for our GUI frontend and REST. 
4. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   22 Jul 2020 in reply to Roger Blanchard

   Link to this post

   Roger, what is the use case where the same user can update a field from the GUI but not via REST?
5. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   22 Jul 2020 in reply to Mike Fechner

   Link to this post

   Lets take the Customer table. We have an existing REST API where we allow web developers access to the Customer info. We limit the info they can see as well as the info they can update.
   
   For example, you walk into your local Pet Store and they want to sign you up as a loyalty customer. Today, if you want to sign up for their loyalty program they will create a new customer record in our POS module with limited info. They do not want to tie up the POS terminal and force the cashier to enter all the customer info. Later, when you are home you can go to the merchants web site and fill out the rest of your info which will include your email address. When you do this (including email) the merchant will send you an electronic coupon. From this same website you can lookup your loyalty points, loyalty dollars, etc. We want to restrict what fields can be updated as we would never want the customer to be able to update fields such as loyalty points, loyalty dollars, etc.
   
   We do not control the web front end. The merchants web developers do so while we can say don't allow these fields to be updated odds are that someone will.
   
   I hope this makes sense to you.
6. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   22 Jul 2020 in reply to Roger Blanchard

   Link to this post

   Well, I try to avoid scenarios where I care about in which application a user is allowed to do what.
   
   Why? Because that means that when you add a new UI for a future use case, or provide that data to another application with a service, I would always have to revisit all business logic and think about from which UI I want to support what. I don't want to change completed business logic ever again.
   
   If a user is allowed to update a field, they should be allowed to do that from any device.
   
   If you are worried about data consistency, that should be taken care of by validation. 
   
   If the update is o.k. from your trusted GUI it should be o.k. from any other device too. Nobody can stop a "bad guy" from getting access to an OpenEdge Class Room Edition and write code talking to your Business Logic through AppServer calls to your business logic. So authentication and authorization on the Backend are the only line of defense.
   
   If now you add restriction for the current web or mobile application into the interface, you might have to lift those restriction when you want to use that same interface for a different application that needs more data.
   
   So generally, we solve users field level authorization through an IFieldAuthorizationProvider implementation (yours or ours).
    
   If this does not convince you, I believe the SESSION:CURRENT-REQUEST-INFO instance should tell you which web handler was used to invoke something on the backend. I haven't looked into that in a while.
   
   But we don't have any form of authorization in the framework out of the box that is dependent on the client or service interface used.
   
   
   
7. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   22 Jul 2020 in reply to Mike Fechner

   Link to this post

   Okay, thanks for the info.
   
   I will take a look at IFieldAuthorizationProvider.