Since we have a work-around this issue will be closed. That does not mean we'll make other changes to improve the situation.. eg compression or otherwise reduce header size.

I was thinking between current perm set naming vs path pattern based naming. There is no rule/convention about current perm set naming, so anyone can name it in anyway, so we could have large number of perm names (individual or set). At certain time point, those perms have to be transferred over the wire and compared. It would be easier and more efficient if there is a consistent naming.

@Hongwei Ji That would help somewhat but for endpoints like "checkout-by-barcode" which has many modulePermissions from various parts of the system it would only slow down the growth. Plus, we could achieve almost the same by just 'compressing' the list with something like "deflate". I think not sending them over in the headers is more bulletproof.

Or maybe pattern based permission naming hierarchy without the the need to expand explicitly to individual permissions. For example, "circulation-storage" or "circulation-storage.*" will implicitly includes all perms that starts with "circulation-storage" like "circulation-storage.loans", "circulation-storage.requests", and etc.

@Adam Dickmeiss @Heikki Levanto

Guys, it looks like https://folio-org.atlassian.net/browse/CIRC-352#icft=CIRC-352 will work as a workaround for Q2 so let's do that.

I would like to propose however that we change how the permissions passing between Okapi and mod-authtoken is done:

• deprecate and remove X-Okapi-Permissions-Desired, X-Okapi-Permission-Required and X-Okapi-Module-Permissions headers and the "extra_permission" property from the token payload

• add "endpoint" property to the token and add ModuleDescriptor lookup to mod-authtoken. Based on the existing "module" and new "endpoint" property, mod-authtoken will be able to retrieve desired, required and module permissions that previously have been available in the token.

Comments?