update docs to explain intended pattern for common code (#58) #78

davepacheco · 2021-01-19T18:41:23Z

Fixes #58.

ahl

typo (I think?) and a very mild suggestion that you should feel free to reject

README.adoc

ahl · 2021-01-19T19:16:59Z

README.adoc

+
+With Dropshot, we wanted to try something different: if the primary purpose of these handlers is to share code between handlers, what if we rely instead on existing mechanisms -- i.e., function calls.  The big risk is that it's easy for someone to accidentally forget some important function call, like the one that authentices or authorizes a user.  We haven't gotten far enough in a complex implementation to need this yet, but the plan is to create a pattern of utility functions that return typed values.  For example, where in Node.js you might add an early authentication handler that fills in `request.auth`, with Dropshot you'd have an authentication function that _returns_ an `AuthzContext` struct.  Then anything that needs authentication consumes the `AuthzContext` as a function argument.  As an author of a handler, you know if you've got an `AuthzContext` available and, if not, how to get one (call the utility function).  This composes, too: you can have an authorization function that returns an `AuthnContext`, and the utility function that returns one can consume the `AuthzContext`.  Then anything that requires authorization can consume just the `AuthnContext`, and you know it's been authenticated and authorized (possibly with details in that structure).
+
+It's early, and we may find we need richer facilities in the framework.  But we're hopeful this approach will make it faster and smoother to iterate on complex API servers.


Suggested change

It's early, and we may find we need richer facilities in the framework. But we're hopeful this approach will make it faster and smoother to iterate on complex API servers.

It's early, and we may find we need richer facilities in the framework. But we're hopeful this approach will make it faster and smoother to iterate on complex API servers. We welcome feedback from folks using or interested in using Dropshot.

Co-authored-by: Adam Leventhal <[email protected]>

update docs to explain intended pattern for common code (oxidecompute…

ceeee45

…r#58)

davepacheco requested a review from ahl January 19, 2021 18:41

ahl approved these changes Jan 19, 2021

View reviewed changes

fix typo

5336af5

Co-authored-by: Adam Leventhal <[email protected]>

davepacheco merged commit c6ed62a into oxidecomputer:master Jan 19, 2021

davepacheco deleted the issue-58 branch January 19, 2021 19:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

update docs to explain intended pattern for common code (#58) #78

update docs to explain intended pattern for common code (#58) #78

davepacheco commented Jan 19, 2021 •

edited

Loading

ahl left a comment

ahl Jan 19, 2021


		With Dropshot, we wanted to try something different: if the primary purpose of these handlers is to share code between handlers, what if we rely instead on existing mechanisms -- i.e., function calls. The big risk is that it's easy for someone to accidentally forget some important function call, like the one that authentices or authorizes a user. We haven't gotten far enough in a complex implementation to need this yet, but the plan is to create a pattern of utility functions that return typed values. For example, where in Node.js you might add an early authentication handler that fills in `request.auth`, with Dropshot you'd have an authentication function that _returns_ an `AuthzContext` struct. Then anything that needs authentication consumes the `AuthzContext` as a function argument. As an author of a handler, you know if you've got an `AuthzContext` available and, if not, how to get one (call the utility function). This composes, too: you can have an authorization function that returns an `AuthnContext`, and the utility function that returns one can consume the `AuthzContext`. Then anything that requires authorization can consume just the `AuthnContext`, and you know it's been authenticated and authorized (possibly with details in that structure).

		It's early, and we may find we need richer facilities in the framework. But we're hopeful this approach will make it faster and smoother to iterate on complex API servers.

update docs to explain intended pattern for common code (#58) #78

update docs to explain intended pattern for common code (#58) #78

Conversation

davepacheco commented Jan 19, 2021 • edited Loading

ahl left a comment

Choose a reason for hiding this comment

ahl Jan 19, 2021

Choose a reason for hiding this comment

davepacheco commented Jan 19, 2021 •

edited

Loading