Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Second iteration of scope configuration #215

Open
asadeg02 opened this issue Jul 15, 2020 · 0 comments
Open

Second iteration of scope configuration #215

asadeg02 opened this issue Jul 15, 2020 · 0 comments

Comments

@asadeg02
Copy link
Member

asadeg02 commented Jul 15, 2020

Description

This task is the second iteration of issue #212 to integrate a database back-up (for keeping the updated scopes) with the first iteration. In the first Iteration of that task we have been able to update the scope of all the registered routes on the UI by updating a permission config file from which the scope of the routes are being read when we are defining them.

Other than serving as a backup storage for routes scopes, another reason for storing the updated scopes in the table is to be able to handle and address a corner case where the developer is updating the scope on the the UI but has forgotten to assign the scope of the routes from permission config file and has some hard coded values for the scope in the route definition, in this case updating the scopes on UI and even updating the config file wouldn't update the actual scope of the routes and won't have any effects.

Context

Before starting the implementation of the second iteration, it might be helpful to think about 2 questions leading to a couple of corner cases:

1- What happens if the developer forgets to assign the scope of routes from the permission config file?

2- What happens if on updating the UI, updating the permission config file fails but updating the corresponding document in database succeeds and vice versa?

Steps

  1. Create a data base model named as RouteScope with a schema of {id:objectId, method:string, path:string, scopes:array, date:Date()}

  2. In the route that you have created for in your first iteration where you are updating the config file, update the RouteScope table with the corresponding changes.

  • first you have to look up the table by method and path of routes to see if it already exists in the
    table, if so you should update the already existing document by calling the right mongo method.
  • if it doesn't exist you should create a new document in the collection by calling insert method.
  1. To handle the corner case mentioned above, in the web route that's replying with the html page (for updating scope created in first iteration), for every documents in RouteScope collection you have to compare the scope with the scope of corresponding route in routing table (server.table()), if the scope arrays are not identical it means that the developer has forgotten to assign the route scope from the config file in the definition so updating the scope on the UI won't have any effects.
    you need to pass these set of routes (which have different scopes in the data base collection and routing table of the server) to the UI template.

  2. On the UI template create a separate section for displaying the set of routes described in number 3 above. (you can show them in a table format).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants