Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make authentication easier to use and fix some things about ErrorV #213

Merged
merged 7 commits into from
May 25, 2024

Conversation

cgibbard
Copy link
Collaborator

@cgibbard cgibbard commented May 8, 2024

The forced polymorphism in handlePersonalAuthMapQuery was preventing use of ErrorV for handling authorization failures (because its operations are intentionally monomorphic).

liftErrorV was not a good primitive to make queries, it would have been fine for reporting success, but did not explicitly register interest in the error part. Because of that, cropV would have quietly deleted the errors from the view. I'd be surprised if anything using this managed to avoid this pitfall.

As such, liftErrorV has been replaced by two new primitives: queryErrorV for registering interest in a view wrapped in ErrorV, and successErrorV for constructing a successful Identity view.

I also removed unsafeProjectE / unsafeProjectV from ErrorV rather than reworking them because the things they did were not entirely sensible to begin with:

  • unsafeProjectE was requesting only errors from the backend, but then discarding those errors from the corresponding view on the way back. If you want that, you ought to avoid registering interest in the ErrorV in the first place, rather than making the backend work to discover that there's an error you're going to ignore.
  • unsafeProjectV was treating failures the same way as lag (which is maybe on a rare occasion something you'd want, but let's not encourage it).

cgibbard and others added 7 commits May 8, 2024 12:24
The forced polymorphism in handlePersonalAuthMapQuery was preventing use
of ErrorV for handling authorization failures (because its operations
are intentionally monomorphic).

liftErrorV was not a good primitive to make queries, it would have been
fine for reporting success, but did not explicitly register interest in
the error part. Because of that, cropV would have quietly deleted the
errors from the view. I'd be surprised if anything using this managed
to avoid this pitfall.

As such, liftErrorV has been replaced by two new primitives:
queryErrorV for registering interest in a view wrapped in ErrorV, and
successErrorV for constructing a successful Identity view.

I also removed unsafeProjectE / unsafeProjectV from ErrorV rather than
reworking them because the things they did were not entirely sensible to
begin with:
* unsafeProjectE was requesting only errors from the backend, but then
  discarding those errors from the corresponding view on the way back.
  If you want that, you ought to avoid registering interest in the
  ErrorV in the first place, rather than making the backend work to
  discover that there's an error you're going to ignore.
* unsafeProjectV was treating failures the same way as lag (which is
  maybe on a rare occasion something you'd want, but let's not
  encourage it).
@ali-abrar ali-abrar merged commit 3d77e73 into develop May 25, 2024
1 check passed
@ali-abrar
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants