Inactive tenant - should not be allowed to login with an appropriate message

[lbathina]

I'm submitting a ...

• bug report
• new feature / enhancement request
• improvement request (usability, performance, tech debt, etc.)
• other

Traffic Control components affected ...

• CDN in a Box
• Documentation
• Grove
• Traffic Control Client
• Traffic Monitor
• Traffic Ops
• Traffic Ops ORT
• Traffic Portal
• Traffic Router
• Traffic Stats
• Traffic Vault
• unknown

Current behavior:

Currently an user of an inactive tenant is able to login and POST , GET and DELETE
ideally POST and DELETE currently return a 500 - another bug raised for it
GET - returns 200 with no items

Expected / new behavior:

instead its pretty easy and straight to have the user not to login with appropriate message saying their tenancy or parent tenancy has been inactive and need to be active to login

Minimal reproduction of the problem with instructions:

Anything else:

[mitchell852]

I think we need a bigger discussion of what tenant.active=false is supposed to do. Should it:

1. set all child tenants active=false as well?
2. prevent all users of that tenant from login? or is login restriction to be only determined by role. i.e. role == disallowed is the only way to prevent a user from logging in.
3. prevent api calls to all tenantable routes of the inactive tenant? Examples:

PUT /deliverservices/42 where 42 is a ds in an inactive tenant return a 400 or something?
PUT /users/88 where 88 is a user in an inactive tenant return a 400 or something?
PUT /tenants/22 where 22 is an inactive tenant return a 400 or something?

what should GET /deliveryservices return if I am part of an inactive tenant? empty array or a 400?

The point is, until we determine the intent of tenant.active, it is hard to say what works and what doesn't work.

[ocket8888]

"Currently an user of an inactive tenant is able to login and POST , GET and DELETE"
"ideally POST and DELETE currently return a 500 - another bug raised for it"
"GET - returns 200 with no items"

Are you saying that specifically it's a problem that users within an inactive Tenant can make POST, GET and DELETE requests to the API? What paths for POST and DELETE are giving 500s? Is that ideal or a bug? What GET is returning an a 200 with no items?

[mitchell852]

i kind of feel like the tenant.active field should simply be removed for now as it appears to have no purpose.