You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The AuthResult datatype offers the Unauthorized constructor, which logically corresponds to a 403 error, but there is no constructor that implies a user lacks the necessary subscription/license for a feature - a 402 error: payment required.
This would be a useful constructor for any proprietary software with paywalled features as 402 and 403 status codes could be handled differently, making it clear to users when a feature isn't available to them (e.g., because of their role) or when a feature is paywalled.
Implementing paywalling like this, at the Authentication level, would give devs control over when to show a paywall and when to show a 'permission denied' page (e.g., if the user lacks a subscription and lacks the required role for a feature, then the spec may be to show them a paywall over showing them the permission denied page, or vice versa). This would also prevent situations where, if a user was to be shown a paywall over a permission denied page, they would need to be authenticated initially (to see the paywall) but unauthenticated on acquiring the necessary subscription for the feature.
The text was updated successfully, but these errors were encountered:
The AuthResult datatype offers the Unauthorized constructor, which logically corresponds to a 403 error, but there is no constructor that implies a user lacks the necessary subscription/license for a feature - a 402 error: payment required.
This would be a useful constructor for any proprietary software with paywalled features as 402 and 403 status codes could be handled differently, making it clear to users when a feature isn't available to them (e.g., because of their role) or when a feature is paywalled.
Implementing paywalling like this, at the Authentication level, would give devs control over when to show a paywall and when to show a 'permission denied' page (e.g., if the user lacks a subscription and lacks the required role for a feature, then the spec may be to show them a paywall over showing them the permission denied page, or vice versa). This would also prevent situations where, if a user was to be shown a paywall over a permission denied page, they would need to be authenticated initially (to see the paywall) but unauthenticated on acquiring the necessary subscription for the feature.
The text was updated successfully, but these errors were encountered: