com.fulcrologic.rad.authorization
Authentication and Authorization Support.
WARNING: This part of RAD will not be standardized for some time. You will need to roll your own particular auth
system, which can easily plug into the various hooks in Forms and Reports (e.g. field formatters, read-only checks, etc).
If necessary you can simply make new wrapper macros around these if/when boilerplate becomes an issue. After all, forms
and reports are just very thin macros around Fulcro's defsc that pre-fill component options for you.
We hope the community will provide plugins for this, but generalized Auth is simply beyond the scope of RAD at this time due
to time/resource constraints. Community members are highly encouraged to write their own auth plugin libraries for
RAD, and we'll be glad to link to them on the main project pages.
The implementation in this namespace is only partially written, and can satisfy some simple needs. The original idea was that each attribute would be under some authority (the owner of that data). These would be identified by user-generated keyword names.
The state machine in this namespace was then meant to be used as a way to check which authorities had been authenticated against, so that incremental data access could be obtained over time as the user moved among features in the application. Each authority requires that the developer provide a component that can be used as the source of the mutation names and (optionally) UI for obtaining data from the user like passwords.
This at least gives you the ability to control if the current user is at least known to the authority in question, but even this requires some integration with the network remotes of your application (are you using cookies? JWT? etc.).
Also: Real Data access has to be ultimately controlled by the data owner. Therefore much of the real work needs to be done work at the network/database layer.
Securing a real application needs the following (most of which RAD does NOT provide a default implementation for):
- A way to auth against a server to establish a session.
- A Pathom parser plugin that can check the query/mutation to see if it should be allowed. ** Optionally: granular query security, where individual attributes can be redacted. This would allow the same UI to be shown for users in different roles, and simple elision at the server can then easily be used to affect field/column visibility in the client.
Some ideas around possible implementations can be found in this package's source directory as auth.adoc.
Authentication and Authorization Support. WARNING: This part of RAD will not be standardized for some time. You will need to roll your own particular auth system, which can easily plug into the various hooks in Forms and Reports (e.g. field formatters, read-only checks, etc). If necessary you can simply make new wrapper macros around these if/when boilerplate becomes an issue. After all, forms and reports are just very thin macros around Fulcro's `defsc` that pre-fill component options for you. We hope the community will provide plugins for this, but generalized Auth is simply beyond the scope of RAD at this time due to time/resource constraints. Community members are highly encouraged to write their own auth plugin libraries for RAD, and we'll be glad to link to them on the main project pages. The implementation in this namespace is only partially written, and can satisfy some simple needs. The original idea was that each attribute would be under some authority (the owner of that data). These would be identified by user-generated keyword names. The state machine in this namespace was then meant to be used as a way to check which authorities had been authenticated against, so that incremental data access could be obtained over time as the user moved among features in the application. Each authority requires that the developer provide a component that can be used as the source of the mutation names and (optionally) UI for obtaining data from the user like passwords. This at least gives you the ability to control if the current user is at least *known* to the authority in question, but even this requires some integration with the network remotes of your application (are you using cookies? JWT? etc.). Also: *Real* Data access has to be ultimately controlled by the data owner. Therefore much of the real work needs to be done work at the network/database layer. Securing a real application needs the following (most of which RAD does NOT provide a default implementation for): * A way to auth against a server to establish a session. * A Pathom parser plugin that can check the query/mutation to see if it should be allowed. ** Optionally: granular query security, where individual attributes can be redacted. This would allow the same UI to be shown for users in different roles, and simple elision at the server can then easily be used to affect field/column visibility in the client. Some ideas around possible implementations can be found in this package's source directory as auth.adoc.
authenticateclj/s
(authenticate any-sm-env provider source-machine-id)Start an authentication sequence for the given provider, and report results to the source-machine-id. This version is identical to authenticate!, but accepts any state machine env as the first parameter.
Sends and :event/authenticated or :event/authentication-failed to that source machine when done.
Start an authentication sequence for the given provider, and report results to the source-machine-id. This version is identical to authenticate!, but accepts any state machine env as the first parameter. Sends and :event/authenticated or :event/authentication-failed to that source machine when done.
authenticate!clj/s
(authenticate! app-ish provider source-machine-id)Start an authentication sequence for the given provider, and report results to the source-machine-id.
Sends and :event/authenticated or :event/authentication-failed to that source machine when done.
Start an authentication sequence for the given provider, and report results to the source-machine-id. Sends and :event/authenticated or :event/authentication-failed to that source machine when done.
failed!clj/s
(failed! app-ish provider)Tell the auth system that the given provider failed.
Tell the auth system that the given provider failed.
logged-in!clj/s
(logged-in! app-ish provider)Tell the auth system that the given provider succeeded.
Tell the auth system that the given provider succeeded.
logout!clj/s
(logout! app-ish provider)Force logout on the given provider.
Force logout on the given provider.
redactclj/s
(redact {attr-map :com.fulcrologic.rad.attributes/key->attribute :as env}
query-result)Creates a post-processing plugin that redacts attributes that are marked as non-readable
Creates a post-processing plugin that redacts attributes that are marked as non-readable
start!clj/s
(start! app authority-ui-roots)(start! app authority-ui-roots options)Start the authentication system and configure it to use the provided UI components (with options).
NOTE: THIS IS NOT A PRODUCTION-READY IMPLEMENTATION. You can use the source of this and its corresponding state machine as a basis for your own, but it needs more work. PRs welcome.
app- The Fulcro app to manage.authority-ui-roots- A vector of UI components with singleton idents. Each must have a unique ::auth/provider (the name of the authority) and ::auth/check-session (a mutation to run that should return a Session from a remote that has looked for an existing session.)options- A map of additional startup options.
Start the authentication system and configure it to use the provided UI components (with options). NOTE: THIS IS NOT A PRODUCTION-READY IMPLEMENTATION. You can use the source of this and its corresponding state machine as a basis for your own, but it needs more work. PRs welcome. * `app` - The Fulcro app to manage. * `authority-ui-roots` - A vector of UI components with singleton idents. Each must have a unique ::auth/provider (the name of the authority) and ::auth/check-session (a mutation to run that should return a Session from a remote that has looked for an existing session.) * `options` - A map of additional startup options.
verified-authoritiesclj/s
(verified-authorities app-ish)Returns the providers that are currently authenticated.
Returns the providers that are currently authenticated.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close