HelloZeroNet / HelloZeroNet/ZeroNet

Allow zites to overwrite, overrule or set an custom auth_address.

Offen
#2,350 8 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
JavaScript
Sterne
18.8k
Forks
2.3k
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

**Is your feature request related to a problem? Please describe.**
To the best of my knowledge, for a zite developer it is currently impossible to change the auth_address at all. Because of this, added certificates will in the eyes of ZeroNet always be intended to be for the current auth_address(which, per zite, cannot change), and also accepted regardless of the signature contents (see this issue). This makes not only anonymous posting impossible but also the ability to have multiple accounts on one zite, since `fileWrite` will only write files, if the current auth_address is in the valid signers list. With no way to change auth_address this is only true for one directory path(which ends in that auth_address). Possible applications for multiple accounts could be a moderation system(possibly even autonomous ones, through election algorithms), where you would have differently privileged user types, as example:

- Owner
- Moderator
- Volunteer
- User As things currently are, a moderator, for example, must always post with his moderator account.

**Describe the solution you'd like**
An api command to either:

- overwrite: Replace the generated auth_address with custom one, but always default to generated one, if the zite developer for example tried to add an invalid privatekey (only either of them is readable at every point in time)
- overrule: Add the custom auth_address as an new field(both are readable at any point in time).
- set: Replace the generated auth_address permanently with the custom one.

An alternative way to implement this would be to allow have an commend like `setAuthIndex` where that will change the auth_address to the subkey of the specified index, similar to the way `userPublickey` from `CryptMessage` plugin does it. But this would be way less flexible than the solutions mentioned above.

In addition to that, in `certAdd` the ability to specify what privatekey the new certificate, actually belongs to and only to assume the current auth_address as default. Something like: `@cmd "certAdd", ["zeroid.bit", auth_type, auth_privkey, user_name, cert_sign], (res) =>{/**Stuff*/}` Where auth_privkey is, if not specified, the private key of the current auth_address.

**Describe alternatives you've considered**
Using current api commands, trying different zite structures and digging through ZeroNet source code to find a way to alter/change the auth_address. None of these I had success with.

**Additional context**
This issue is mirrored from the [GitCenter ZeroNet repository](http://127.0.0.1:43110/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/repo/issues/view/?1P4w4Rvh4vS9r6G5xTiSh8qEW87EKZtnJB/8@1DfrA2M9Qra6stqT6tzwNMYNweswY54KAC)(you need to install ZeroNet to visit this link)

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.