[GH-ISSUE #346] [Feature Request] Edit API Premissions / Access #848

New issue

Closed

opened 2026-03-14 10:52:22 +03:00 by kerem · 1 comment

kerem commented

2026-03-14 10:52:22 +03:00

Owner

Originally created by @Zaptosis on GitHub (Oct 11, 2022).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/346

It would be great if one could allow a family member or trusted friend to use a custom domain, however adding authorized users or shared domains would be a pretty large & complex feature to add.

Instead a temporary workaround that would be much easier to implement would would be setting API keys access scopes, which would also have the benefit of increasing security rather than just having fully unrestricted API keys floating around while also enabling other use cases outside of this.

Such API options could be:

Allow Adding / Removing Recipients
Limit Recipient Access (then check authorized recipients, this limits the API key to only view, edit, & add domains to an authorized pre-added recipient)
Allow domain management
Allow Rules Management
Allow Account Management
Allow deleting aliases (if enabled it would still be limited by authorized recipients if "limit recipient access" is enabled)
Etc, I'm sure many others could be added.

To avoid further cluttering the UI just a simple "edit" button could be added for the API key next to the delete button. It also wouldn't significantly increase costs as both lite & pro users would still be limited by their maximum bandwidth allocation & maximum recipient allocation.

This is an easy low-cost way to massively expand the functionality of AnonAddy & increase its competitiveness in the space.

Originally created by @Zaptosis on GitHub (Oct 11, 2022). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/346 It would be great if one could allow a family member or trusted friend to use a custom domain, however adding authorized users or shared domains would be a pretty large & complex feature to add. Instead a temporary workaround that would be much easier to implement would would be setting API keys access scopes, which would also have the benefit of increasing security rather than just having fully unrestricted API keys floating around while also enabling other use cases outside of this. Such API options could be: - Allow Adding / Removing Recipients - Limit Recipient Access _(then check authorized recipients, this limits the API key to only view, edit, & add domains to an authorized pre-added recipient)_ - Allow domain management - Allow Rules Management - Allow Account Management - Allow deleting aliases _(if enabled it would still be limited by authorized recipients if "limit recipient access" is enabled)_ - Etc, I'm sure many others could be added. To avoid further cluttering the UI just a simple "edit" button could be added for the API key next to the delete button. It also wouldn't significantly increase costs as both lite & pro users would still be limited by their maximum bandwidth allocation & maximum recipient allocation. This is an easy low-cost way to massively expand the functionality of AnonAddy & increase its competitiveness in the space.

kerem closed this issue

2026-03-14 10:52:27 +03:00

kerem commented

2026-03-14 10:52:33 +03:00

Author

Owner

@willbrowningme commented on GitHub (Oct 19, 2022):

Thanks for the suggestion, Laravel Sanctum does make it easy to assign abilities (scopes) to tokens - https://laravel.com/docs/9.x/sanctum#token-abilities

I would likely keep the scopes as create, read, update, delete for each resource (e.g. aliases, recipients, domains).

My only concern is error handling for things like the browser extension and mobile apps if someone uses a token with incorrect abilities/scopes.

When I get time I'll see if I can implement this.

@willbrowningme commented on GitHub (Oct 19, 2022): Thanks for the suggestion, Laravel Sanctum does make it easy to assign abilities (scopes) to tokens - https://laravel.com/docs/9.x/sanctum#token-abilities I would likely keep the scopes as `create, read, update, delete` for each resource (e.g. aliases, recipients, domains). My only concern is error handling for things like the browser extension and mobile apps if someone uses a token with incorrect abilities/scopes. When I get time I'll see if I can implement this.

No labels

bug

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/anonaddy#848

No description provided.

Rows
Columns