How Offices are Determined

[krowvin]

There was a side conversation in a Pull Request that I thought suited to put here for future ideas/brainstorming.

Here is a paste of some bits I pulled from the PR, but you can read it in it's entirety (here)

PR tidbits

However, since each object MUST have the office anyways

But if the user has more than one office it can't pick a default.

if you don't set the office at all things can go haywire changing the user

The office queryParam was already there on most endpoints because of the need to sometimes use it in a query.

Most endpoints have an "office" parameter, and all the dto's have an office parameter.

Without knowing all the use-cases for how the session office id is used, it seems scary to me to hide it away in the DTO.

Alternatively an additional explicit header, like X-CWMS-Auth-Office, could be set on each call that requires it separate from the query parameter.

Here are some naïve thoughts I had about automagically determining the office

1. I think the X-CWMS-Auth-Office is a great idea as it serves the auth need and allows setting the office globally (which could remove the need for the office param)

   1. this is also great because this header could be handled in any wrappers (CWMSpy/jy/js/etc) where the dev can specify it or a dropdown is created similar to what CWMS-Vue has with selecting the server
   2. Districts could also chose to override this at the reverse proxy level, if for whatever reason they needed that???

2. Whenever a user choses an office param it should override the set header for the proceeding data fetch (but not the auth)

3. Some other ideas on trying to determine office without user/dev inputs
   In no particular order

   1. bounding office table, references locations to predetermined bounding offices (updating nightmare)
   2. Use shape files of each district's boundaries to compare against the lat/lon of a given gage to determine who owns that gage, use this as a starting point, and let offices override.
   3. Use the "belongs to" field in the database for a location, let offices override, and expect them to update what gages belong to them (or create another column for use with CDA)

Overrides (header/param) would overwrite all of the options in 3

[MikeNeilson]

Generally this only really matters during authorizing a write/change operation, though it could for read in the future.
The more I think about it I think the approach of each DTO MUST include the owning office (which could be CWMS, the idea being things like automated processes of say shared data sources would have access), So the DAOs will be able to just use that and set the office just before store. For gets it could check the X-CWMS-Auth-office header and set the session if required. (and in the future just use it.)

[adamkorynta]

I don't like the idea of there being multiple places to check for the session office id. It would only complicate debugging issues. It seems we need to make a decision between encapsulating the CWMS schema session office or exposing that as part of this API as well.

Putting it in the header exposes it, but it also lets us test for where it is actually used. If we want to tackle removing unintentional session id usages within the CWMS schema we can write tests leaving the header out. We wouldn't be able to do the same thing by leaving the DTO office out.

[adamkorynta]

I don't like the parameter as it becomes difficult enforcing the "office" parameter being used as a mask or a literal. Having a header for gets and not for writes seems very murky.

[MikeNeilson]

Yeah. I think the main usage of office queryParam we have right now is correct, just limiting queries, and some other mechanism should be used for required authentication.

The DTO makes the most sense to me during storage, again, since we definitely need to call the database functions with an office value so it's right there.

I think I'd like to start there. Moving the office value up to the root of the DTO objects, and then leave one place.

Trying to think about how this work work in the future without the API and that just seems the simplest long term.

[adamkorynta]

This makes a lot of sense to me. And I like encapsulating the session office as any CDA user shouldn't care about it.

[rma-rripken]

The office could also be associated with an api-key. I'm not sure how this would work with all the various ways we're considering doing authentication but the creation of a user key is analogous to a new user session. So if the office is supposed to exist in the session it seems like it would be associated with the key. Not sure how the user specifies what office they want a key for - is that a drop down on the login dialog? Is there a different login end-point for each office? An extra parameter to the login process? idk how it would work. Seems like it should at least be considered.

[MikeNeilson]

With the API Key anything beyond "valid key" would have to be stored in the database, that's the point of that type of system.

But I think the conclusion we've come to is that the user doesn't really need to assert the office in general, but the required office needs to known at point of store. For example if I wanted to store a list of location and one one for SPK and one for LRL (why I would do that, let's not go there) it doesn't make sense to then set the office somewhere.

The DTO is the natural location for the value as it's not a critical component of the user session, but a critical element of the object being stored, or retrieved (but for retrieve that's more database design issue at the moment.)

So the idea would be the auth handlers get the userid ready, and the next element handles the office if required.

[MikeNeilson]

... it is most unfortunate that our baseline roles are Office based. Like the manager checks for "has the CWMS User role" but that role is per office.

However, I think I can get away with "has role in anyoffice" for the initial check.

[MikeNeilson]

Whelp, I've hit a, fortunately somewhat minor, snag.

The idea of handling the office at the DTO (and in the case of some deletes parameter) level does work and the code change for that wasn't super extreme.

However, the function that actually set the user for the session fails because the "office" from the previous session is either active and the next user might not have it or the next user doesn't have and it has to be set first.

The good news is, relatively simple fix. Going to change that function (or add one) that also takes the office so it can just set it correctly. Bad news is, that fix has to be done at the database. On the otherhand, it means we can just delete the whole "DataSourcePreparer" concept. (Note that I'm out to murder it, specifically it did what we needed at the time, but if we can simplify we should.)

So this effort is going to include a little more change than I wanted. Not just the DTO changes themselves, but also rearranging the the auth code. Unfortunately for testing all needs to be done at once, but fortunately we have that set of tests.