[{"_1":2,"_153":-5,"_154":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_132":133},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_23":24,"_25":-5,"_26":11,"_27":11,"_28":29,"_30":31,"_32":-5,"_33":11,"_34":35,"_84":-5,"_85":86,"_125":-5,"_126":11,"_127":17,"_128":11,"_129":-5,"_130":131},"canonicalUrl","https://hub.docker.com/r/flowofcontrol/mu-authorization/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","flowofcontrol","reponame","mu-authorization","cloudBuildSource","isAutobuildsAvailable","repo",{"_36":37,"_38":39,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":51,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":70,"_75":11,"_76":77,"_81":29,"_82":83},"categories",[],"content_types",[40],"image","date_registered","2021-02-09T13:52:07.681854Z","description","","is_private","last_updated","2021-02-09T17:39:52.114688Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[52],"application/vnd.docker.container.image.v1+json","name","pull_count",343,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","[![Hex version badge](https://img.shields.io/hexpm/v/sparqlex.svg)](https://hex.pm/packages/sparqlex)\n[![License badge](https://img.shields.io/hexpm/l/sparqlex.svg)](https://github.com/langens-jonathan/sparql/blob/master/LICENSE)\n\n# mu-authorization (aka SEAS)\nThe SPARQL endpoint authorization service (SEAS) is a layer that is placed in front of a SPARQL endpoint and that rewrites queries on this endpoint based on the session information of the user and the access rights on the data.\n\nThe idea is that data is organized into graphs and the access to these graphs is restricted to a certain set of roles. Each set of roles is associated with a group. When an INSERT query is sent to the SPARQL endpoint it is intercepted by SEAS. SEAS then loops through its different group specifications and, per specification, distributes the triples across different graphs when they match the graph's constraint. When a service later tries to read data through SEAS, the session is examined and the access criterion of every group is evaluated. If the user has access to the group, the service is allowed to read from the group's graph.\n\n## Tutorials\n### Add mu-authorization to a stack\nYour current stack contains a triplestore (Virtuoso, Blazegraph, ....). Because we will put mu-authorization in front of this triplestore, look up the name of the triplestore service in your `docker-compose.yml` file and rename it to `triplestore`.\n\nE.g.\n\n```yml\nservices:\n database:\n image: tenforce/virtuoso\n ...\n```\nshould be updated to\n\n```yml\nservices:\n triplestore:\n image: tenforce/virtuoso\n ...\n```\n\nNext, add the mu-authorization service to the `docker-compose.yml` file by adding the following snippet:\n\n```yml\nservices:\n database:\n image: semtech/mu-authorization:0.6.0-beta.5\n environment:\n MU_SPARQL_ENDPOINT: \"http://triplestore:8890/sparql\"\n volumes:\n - ./config/authorization:/config\n\n```\n\nThis snippet is typically added just above the `triplestore` service.\n\nCreate a file `./config/authorization/config.ex` with the following contents:\n\n```elixir\nalias Acl.Accessibility.Always, as: AlwaysAccessible\nalias Acl.GraphSpec.Constraint.Resource, as: ResourceConstraint\nalias Acl.GraphSpec, as: GraphSpec\nalias Acl.GroupSpec, as: GroupSpec\nalias Acl.GroupSpec.GraphCleanup, as: GraphCleanup\n\ndefmodule Acl.UserGroups.Config do\n def user_groups do\n # These elements are walked from top to bottom. Each of them may\n # alter the quads to which the current query applies. Quads are\n # represented in three sections: current_source_quads,\n # removed_source_quads, new_quads. The quads may be calculated in\n # many ways. The useage of a GroupSpec and GraphCleanup are\n # common.\n [\n # // PUBLIC\n %GroupSpec{\n name: \"public\",\n useage: [:read],\n access: %AlwaysAccessible{},\n graphs: [ %GraphSpec{\n graph: \"http://mu.semte.ch/graphs/public\",\n constraint: %ResourceConstraint{\n resource_types: [\n ]\n } } ] },\n\n # // CLEANUP\n #\n %GraphCleanup{\n originating_graph: \"http://mu.semte.ch/application\",\n useage: [:write],\n name: \"clean\"\n }\n ]\n end\nend\n```\n\nStart your stack using `docker-compose up -d`. The authorization service will be created.\n\n*Note that you will probably not see any data in your application until you've correctly configured the authorization rules in `./config/authorization/config.ex`.*\n\n## How-to guides\n### Make data publicly available for unauthenticated users\nThis guide describes how to make data publicly available for unauthenticated users, i.e. users without any information attached to their session.\n\nThis guide assumes you've already added mu-authorization to your application as described in \"Tutorial: Add mu-authorization to a stack\" and that data is currently stored in the graph `http://mu.semte.ch/application`.\n\nFirst, open `./config/authorization/config.ex` and make sure there is a `%GroupSpec` named `public` in the `user_groups` function like:\n```elixir\n%GroupSpec{\n name: \"public\",\n useage: [:read],\n access: %AlwaysAccessible{},\n graphs: [ %GraphSpec{\n graph: \"http://mu.semte.ch/graphs/public\",\n constraint: %ResourceConstraint{\n resource_types: [\n ]\n } } ] },\n```\n\nNext, add all resource types (rdf:Class) that you want to make publicly available to the `resource_types` array in `%ResourceConstraint`.\n\nE.g.\n\n```elixir\n%GroupSpec{\n name: \"public\",\n useage: [:read],\n access: %AlwaysAccessible{},\n graphs: [ %GraphSpec{\n graph: \"http://mu.semte.ch/graphs/public\",\n constraint: %ResourceConstraint{\n resource_types: [\n \"http://www.w3.org/ns/dcat#Catalog\",\n \"http://www.w3.org/ns/dcat#Dataset\",\n \"http://www.w3.org/ns/dcat#Distribution\"\n ]\n } } ] },\n```\n\nRestart the authorization service to pick up the updated config:\n\n```bash\ndocker-compose restart database\n```\n\nNext, move the data in your database from the graph `http://mu.semte.ch/application` to the graph `http://mu.semte.ch/graphs/public`. If your stack contains the [mu-migrations-service](https://github.com/mu-semtech/mu-migrations-service), you can generate a migration like:\n```sparql\nDELETE {\n GRAPH {\n ?s ?p ?o .\n }\n} INSERT {\n GRAPH {\n ?s ?p ?o .\n }\n} WHERE {\n GRAPH {\n ?s a ?type ; ?p ?o .\n VALUES ?type {\n \n \n \n }\n }\n}\n```\n\nOtherwise, you can execute the SPARQL query above directly on the SPARQL endpoint of your triplestore (e.g. http://localhost:8890/sparql).\n\nNow that the data has been moved in the triplestore, we just need to make sure that anonymous users landing in our application are associated with the `public` group. The default groups for a user are configured through an environment variable on [mu-identifier](https://github.com/mu-semtech/mu-identifier).\n\nOpen `docker-compose.yml` and add the following environment variable to the `identifier` service:\n```yml\nservices:\n identifier:\n image: semtech/mu-identifier\n environment:\n DEFAULT_MU_AUTH_ALLOWED_GROUPS_HEADER: \"[{\\\"variables\\\":[],\\\"name\\\":\\\"public\\\"}]\"\n```\n\nRestart your stack using `docker-compose up -d`.\n\nYou should now be able to retrieve resources of the specified resource types in your application.\n\n## Reference\n### Mounted configuration files\nmu-authorization can receive a configuration file for the [user groups](#user-groups-configuration) as well as for the [delta system](#delta-system).\n\nA standard mu-semtech stack ensures the configuration files are stored in `./config/authorization/`. They can be mounted in the mu-authorization service by adding the following volume in your `docker-compose.yml`:\n\n```yml\nservices:\n database:\n image: semtech/mu-authorization\n volumes:\n - ./config/authorization:/config\n```\n\nThe contents of the configuration files is explained in depth in the sections on [authorization configuration](#user-groups-configuration) and [delta system](#delta-system).\n\n### User groups configuration\nAuthorization in SEAS is based on group access rules. Groups have read and/or write access to one or multiple graphs based on constraints applied on the data. The group(s) access rules that are applicable for a user are determined based on his session information.\n\nThe user groups should be accessible either on `/config/user_groups.ex` or in `/config/config.ex`. In your standard mu-semtech stack you'll probably save this in `./config/authorization/user_groups.ex`.\n\nThe most import function in the configuration file for SEAS is the `user_groups` function. This function returns the entire configuration regarding groups known to SEAS. The structure of its return type is explained in detail below.\n\n#### Aliases\nTo make the configuration more concise and readable, the following aliases can be configured on top of the configuration file:\n\n```elixir\nalias Acl.Accessibility.Always, as: AlwaysAccessible\nalias Acl.Accessibility.ByQuery, as: AccessByQuery\nalias Acl.GraphSpec.Constraint.Resource.AllPredicates, as: AllPredicates\nalias Acl.GraphSpec.Constraint.Resource.NoPredicates, as: NoPredicates\nalias Acl.GraphSpec.Constraint.ResourceFormat, as: ResourceFormatConstraint\nalias Acl.GraphSpec.Constraint.Resource, as: ResourceConstraint\nalias Acl.GraphSpec, as: GraphSpec\nalias Acl.GroupSpec, as: GroupSpec\nalias Acl.GroupSpec.GraphCleanup, as: GraphCleanup\n```\n#### GroupSpec\nThe result of the `user_groups` function is a list of GroupSpec objects. Every such object specifies a group access rule.\n\nThe properties of a `GroupSpec` are:\n\n- **name:** the name of the group specification rule. Must be unique.\n- **useage:** a list of usage restrictions, from the set `:read`, `:write`, `:read_for_write`. `:read` and `:write` are obvious, `:read_for_write` means the data can be read while doing update queries only.\n- **access:** defines which users belong to the group. See [Access rules](#access-rules).\n- **graphs:** array of [graph specifications](#graphspec) describing the graph(s) in which the data of the group is stored.\n\nIt's worth noting that a group access rules doesn't map one-on-one with traditional user groups. On the contrary, a group access rule may be applicable for multiple users groups. For example, a group access rule may specify the access rule for administrators of a company, but there is an administrator user group for each company (e.g. a user group \"administrators of company X\", a user group \"administrators of company Y\", etc.).\n\n#### Access rules\nAn access rule determines whether a user complies with a group specification and to which exact user group(s) he belongs.\n\nThere are two kinds of access rules: `AlwaysAccessible` and `AccessByQuery`.\n\n##### AlwaysAccessible\nA rule that simply gives access to all users regardless of their session information.\n\n##### AccessByQuery\nA rule that gives access according to a certain SPARQL query.\n\nAn `AccessByQuery` object has two properties:\n\n- **query:** a SPARQL query string that computes the access for the current user. This query is typically based on the information attached to the user's session. `` can be used as a placeholder in the SPARQL query and is replaced with the URI of the current session at runtime.\n- **vars:** array of strings specifying the relevant variables exported/returned by the SPARQL query. The names should exactly match the variable names as returned in the `SELECT` block of the query. The variables will be consumed by the corresponding [`GraphSpecs`](#graphspec) of the group access rule.\n\nAn access rule granting access to all users with the role `SuperMegaAdmin` looks as follows:\n```elixir\n%AccessByQuery{\n vars: [\"session_group_id\",\"session_role\"],\n query: \"PREFIX ext: \n PREFIX mu: \n\n SELECT ?session_group ?session_role WHERE {\n ext:sessionGroup/mu:uuid ?session_group_id;\n ext:sessionRole ?session_role.\n FILTER( ?session_role = \\\"SuperMegaAdmin\\\" )\n }\n\" }\n```\n\nMake sure to correctly escape special characters in the query.\n\nIf the query returns any results, the user has access. For every set of returned variables, a graph URI is resolved to use in the [`GraphSpecs`](#graphspec) part of the group access rule.\n\n#### GraphSpec\nA `GraphSpec` object defines which graph is created and which triples are added to this graph based on constraints on the data.\n\nEach of these `GraphSpec` object holds the following properties:\n\n- **graph:** the (base) URI of the graph that should be created. The URI is appended with the results of the `vars` property of the `GroupSpec`'s [access rule](#access-rule). For instance, if the graph URI is `http://myorganization.org/group` and the `vars` array of the access rule is `['group_id', 'group_name']`, the graph being created will be something like `http://myorganization.org/group/9b2a5053-0967-425c-a1ee-c9b9bfe38b81/awesome_admins`.\n- **constraint:** the [constraint](#constraints) that determines which triples should be sent to/read from the graph.\n\nThe `graphs` property of a `GroupSpec` object contains an array of `GraphSpec` objects. I.e. data accessible for a group may be spread across multiple graphs. The `constraint` property defines in which graph a triple is stored.\n\n#### Constraints\nA constraint defines which triples will be sent to or read from a graph. This section makes abstraction of whether triples are read from or written to the graph as the principle is the same. Both actions will be described as 'sent to the graph'.\n\nThere are two kinds of constraints, a `ResourceFormatConstraint` and a `ResourceConstraint`.\n\n##### ResourceFormatConstraint\nA `ResourceFormatConstraint` defines a constraint on the format of the subject URI of a triple. It has just one property `resource_prefix` which contains a URI. All triples having a subject URI starting with this prefix will be sent to the graph.\n\nIn the example below all triples having a subject that starts with `http://data.myorganization.org/` will be sent to the graph `http://mu.semte.ch/graphs/public`.\n```elixir\n%GraphSpec{\n graph: \"http://mu.semte.ch/graphs/public\",\n constraint: %ResourceFormatConstraint{\n resource_prefix: \"http://data.myorganization.org/\"\n } }\n```\n\n##### ResourceConstraint\nA `ResourceConstraint` allows to put a constraint on the type (rdf:Class) of a resource and/or the predicate of a triple.\n\nA `ResourceConstraint` has the following properties:\n- **resource_types**: a list of type URIs. Resources with this type will be sent to the graph.\n- **predicates**: an additional constraint put on the predicates of such resources that will be sent to the graph. This property is optional. This constraint is either an `AllPredicates` (default) or a `NoPredicates` object with an optional `except` array of predicate URIs.\n\nIn the first example below no properties of a `foaf:Person` will be written to the graph `http://mu.semte.ch/graphs/public`, expect for the person's `foaf:name` and `foaf:accountName`. In the second example all properties of a person will be written to the graph `http://mu.semte.ch/graphs/public` except for the person's `foaf:birthday`.\n```elixir\n%GraphSpec{\n graph: \"http://mu.semte.ch/graphs/public\",\n constraint: %ResourceConstraint{\n resource_types: [\n \"http://xmlns.com/foaf/0.1/Person\" ],\n predicates: %NoPredicates{\n except: [\n \"http://xmlns.com/foaf/0.1/name\",\n \"http://xmlns.com/foaf/0.1/accountName\" ] }\n } }\n```\n\n```elixir\n%GraphSpec{\n graph: \"http://mu.semte.ch/graphs/public\",\n constraint: %ResourceConstraint{\n resource_types: [\n \"http://xmlns.com/foaf/0.1/Person\" ],\n predicates: %AllPredicates{\n except: [\n \"http://xmlns.com/foaf/0.1/birthday\" ] }\n } }\n```\n\n### Delta system\nFor each update query mu-authorization executes it calculates the delta, i.e. which triples have been added and which triples have been removed. These delta messages can be sent to interested clients.\n\n#### Delta clients configuration\nThe services allows to configure which clients will receive those delta messages. This file needs to be accessible on `/config/delta.ex` inside the docker container.\n\nThe delta config file specifies a list of target services to send the delta messages to. The docker service names - as they are known to the mu-authorization service - can be used in the URLs.\n\n```elixir\ndefmodule Delta.Config do\n def targets do\n [ \"http://delta-notifier\" ]\n end\nend\n```\n\nCurrently the most used client for delta messages is the [delta-notifier](https://github.com/mu-semtech/delta-notifier#delta-formats) which allows to forward delta requests to other services based on pattern matching.\n\n#### Delta format\nThe format of the delta messages is explained in the [README of the delta-notifier](https://github.com/mu-semtech/delta-notifier#delta-formats).\n\n### SPARQL endpoint and triplestore\nThe mu-authorization service is a layer that is placed in front of a SPARQL endpoint. The service makes some assumptions regarding the SPARQL endpoint which can be altered. The location of the triplestore as well as alterations to support specific triplestores can be configured.\n\n#### Location of the SPARQL endpoint\nThe default SPARQL endpoint mu-authorization sends SPARQL queries to can be configured with the `MU_SPARQL_ENDPOINT` environment variable. The default is configured on `http://database:8890/sparql` when running inside a standard container but you can override it in the `docker-compose.yml` file. In case this variable is not set (as would be the case in a standard development setup), `http://localhost:8890/sparql` will be used as a default setting.\n\n#### Database compatibility\nCompatibility layers can rewrite SPARQL queries to be in line with the expectations of a triplestore. Use the `DATABASE_COMPATIBILITY` environment variable.\n\nSometimes triplestores can be a bit cranky. mu-authorization tries to create sensible and valid SPARQL queries that express what it intends to achieve. Although it's still a work in progress, it's the goal to generate clean SPARQL queries. A triplestore could barf on a query but work with a rewritten version. The compatibility layer solves that.\n\nSupported values for `DATABASE_COMPATIBILITY` are:\n- `Raw` : (default) Don't alter queries.\n- `Virtuoso` : Support for Virtuoso. Currently rewrites DELETE DATA to DELETE WHERE.\n\n\n### Logging\nLogging can be configured using environment variables. These properties can be set in the environment block in the `docker-compose.yml`.\n\nFlags which can be either on or off translate the environment variable string to an understood configuration. Following are considered true: [`\"true\"`, `\"yes\"`, `\"1\"`, `\"on\"`], all other strings are considered to be false.\n\n- `LOG_OUTGOING_SPARQL_QUERIES` : Logs outgoing SPARQL queries by printing them on the console\n- `INSPECT_OUTGOING_SPARQL_QUERIES`: Logs outgoing SPARQL queries by inspecting them (native string format)\n- `LOG_INCOMING_SPARQL_QUERIES`: Logs incoming SPARQL queries by printing them on the console\n- `INSPECT_INCOMING_SPARQL_QUERIES`: Logs incoming SPARQL queries by inspecting them (native string format)\n- `LOG_SERVER_CONFIGURATION`: Logs some information about the server configuration on boot\n- `LOG_ACCESS_RIGHTS` : Logs the incoming access rights\n- `INSPECT_ACCESS_RIGHTS_PROCESSING` : Logs the processing of the access rights (verbose debugging)\n- `LOG_DELTA_MESSAGES` : Allows logging of delta messages as they're sent to other consumers\n- `LOG_DELTA_CLIENT_COMMUNICATION` : Allows logging of the communication caused by the delta system\n- `LOG_TEMPLATE_MATCHER_PERFORMANCE` : Emits information regarding use of precalculated templates when analysing queries\n- `LOG_OUTGOING_SPARQL_QUERY_RESPONSES` : Logs the responses coming back from the backing triplestore\n- `INSPECT_OUTGOING_SPARQL_QUERY_RESPONSES` : Inspects the responses coming back from the backing triplestore\n- `LOG_OUTGOING_SPARQL_QUERY_ROUNDTRIP` : Logs both the request and the response to/from the backing triplestore closely together in the logs\n\n### Query timeout configuration\nComplex SPARQL queries can take a long time to process and execute. The time mu-authorization is allowed to spend on this processing and execution before timing out can be configured through the following environment variables:\n\n- `QUERY_MAX_PROCESSING_TIME` : Maximum amount of time in milliseconds in which the query should have been processed. Beyond this time, a 503 response may be sent. Take into account that, in practice, the actual consumed time might be substantially larger than the configured time.\n- `QUERY_MAX_EXECUTION_TIME` : Maximum amount of time in milliseconds in which a single query to the triplestore should have been processed. If the query takes longer the connection will be closed and the query failure mechanism will be executed potentially executing the same query again. In case of Virtuoso, a similar setting exists in the virtuoso.ini.\n\n### Database overload recovery\nIt is possible too many queries are sent to mu-authorization, making it go in overload. An experimental system exists to limit this overload.\n\n- `DATABASE_OVERLOAD_RECOVERY` : Enables the overload recovery system. Note that this has not been tested and may not yet help in case of failure.\n- `LOG_DATABASE_OVERLOAD_TICK` : Logs a message whenever the database overload system executes a recalculation. Helps to see if it's still alive.\n\nThe service also provides a `/recovery-status` endpoint to get some info on the status of the recovery system.\n\n### Other configuration\nSome configuration doesn't fit in previous topics. These settings are described in this section.\n\n- `ERROR_ON_UNWRITTEN_DATA` : It may be that you request to write manipulations which will not be written to the triplestore because you do not have the necessary rights. Turning this flag on will make the full manipulation fail in that case.\n- `TESTING_AUTH_QUERY_ERROR_RATE`: Chance a query should fail to execute when trying to test fault-tolerance of consuming services, float ranging [0,1]\n\n\n### Gotchas\n- Authorization examines the graphs the user has access to when writing triples and only writes to graphs a triple belongs to. If no such graph exists, nothing is written to the endpoint. A 201 status code is returned nonetheless.\n- Services should always strive to use SEAS to access the database. If session information is not necessary or should not be applied because the service validates access rights in its own way, the header `mu-auth-sudo` should be set to `true` in the SPARQL request sent to the service.\n- not all services can always use the SEAS because some triple patterns may not be understood by the service's rewrite rules. Note that a service should strive to be compliant with the SEAS service and I have yet to see a case where this is not possible. In a case where it is not possible to use SEAS, the service needs to write it's data to all graphs SEAS would normally write to. This is tough, hence the advice to always use SEAS.\n","has_starred","hub_user","immutable_tags_settings",{"_71":11,"_72":73},"enabled","rules",[74],".*","is_automated","permissions",{"_78":17,"_79":11,"_80":11},"read","write","admin","user","storage_size",79229663,"orgData","recentTags",[87],{"_88":40,"_89":90,"_91":92,"_93":94,"_95":96,"_46":114,"_115":90,"_116":29,"_117":52,"_53":118,"_119":120,"_121":104,"_122":114,"_123":112,"_124":17},"content_type","creator",637872,"full_size",70980646,"id",136893175,"images",[97],{"_98":99,"_100":101,"_102":44,"_103":104,"_105":106,"_107":108,"_109":44,"_110":-5,"_111":92,"_59":112,"_113":-5},"architecture","amd64","digest","sha256:95b8e41145846e427d0f2481a4212ac41938cbe7dde0b673799cf65a73b563cf","features","last_pulled","2026-08-19T09:35:14.833287577Z","last_pushed","2021-02-09T17:39:52Z","os","linux","os_features","os_version","size","inactive","variant","2021-02-09T17:39:51.78949Z","last_updater","last_updater_username","media_type","latest","repository",11354234,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_34":134,"_141":142,"_130":151,"_152":11},{"_36":135,"_38":136,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":137,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":138,"_75":11,"_76":140,"_81":29,"_82":83},[],[40],[52],{"_71":11,"_72":139},[74],{"_78":17,"_79":11,"_80":11},"tags",{"_143":60,"_144":-5,"_145":-5,"_146":147},"count","next","previous","results",[148],{"_88":40,"_89":90,"_91":92,"_93":94,"_95":149,"_46":114,"_115":90,"_116":29,"_117":52,"_53":118,"_119":120,"_121":104,"_122":114,"_123":112,"_124":17},[150],{"_98":99,"_100":101,"_102":44,"_103":104,"_105":106,"_107":108,"_109":44,"_110":-5,"_111":92,"_59":112,"_113":-5},[],"canDeleteTags","actionData","errors"]

flowofcontrol/mu-authorization

Tags for flowofcontrol/mu-authorization