search

signebedi / gita-api

a RESTful Bhagavad Gita API
GNU Affero General Public License v3.0
0 stars 0 forks source link

Add support for corpus-by-corpus scope #107

Open signebedi opened 8 months ago

signebedi commented 8 months ago

Flask signing allows scopes to be set as a list. Right now, all users can view all corpora. But, since #35, we've made it possible to load multiple corpora, so it naturally follows that we would allow access scopes for individual users to be limited either by default, by admin action, or - if we go down this route - based on subscription expiry.

This would be a somewhat complex feature to implement in that the signing key is located in two places - so, changes to a user's scope would need to happen (presumably) in the User model as well as the Signing model unless we want to be reading in some instances from two tables... right?

signebedi commented 8 months ago

Part of this might be handled by setting a "default_access" bool in corpora.json, where corpora with this set to true will be viewable by all users by default An alternative approach would be to define access logic in the app config, but that is, I think, maybe more clunky especially since the app config does not usually handle corpora-specific configs.

signebedi commented 7 months ago

Upon consideration, one thing is clear: we should not store information about corpus-by-corpus user scope in the config, which will work against the generalization of the flask app and make it more difficult to maintain if we don't set and maintain (insofar as we are able) boundaries between the app itself and the underlying substantive logic, which should be segmented and, in cases where we need to break assumptions about the separation of app and logic, we should document it clearly in the code itself. As such, maybe we can inherit a user scope from the app logic when we are implementing the rest api (gita.SOME_CORPUS_SCOPE_LOGIC())....

As such, we should not implement this in the User model which, again, should be generalizable. Instead, we should modify the scope in the Signing table created by flask signing, and then use application logic to set and change default scopes. This should be in the custom logic section with the expectation then that re-implementations of the flask app should have their own custom logic sections that pass their own scope logic that sets defaults and is used to assess signing key access at runtime.