fediversity/fediversity

Watch

Fork 10

Wire up passing credentials from FediPanel to the Pixelfed configuration #190

New issue

Closed

opened 2025-02-24 11:32:12 +01:00 by kiara · 7 comments

kiara commented

2025-02-24 11:32:12 +01:00

Owner

As a Fediversity user,
I want to choose my initial user credentials,
so that I can log in to my Pixelfed instance.

Test:

Given that I am in the panel,
when I am filling the deployment form,
then I should be able to specify my initial credentials such that I can log in to my deployed instance.

implementation notes

proper approach: use LDAP (#615)

**As** a Fediversity user, **I want** to choose my initial user credentials, **so that** I can log in to my Pixelfed instance. Test: **Given** that I am in the panel, **when** I am filling the deployment form, **then** I should be able to specify my [initial credentials](https://git.fediversity.eu/Fediversity/Fediversity/pulls/215/files#diff-c959e516a3e7e73b06277e1352072cd290f6d96b) such that I can log in to my deployed instance. ### implementation notes - proper approach: use LDAP (#615)

kiara added a new dependency

2025-02-24 11:32:56 +01:00

#178 admin accounts provisioned for deployed services

kiara added a new dependency

2025-02-24 11:35:07 +01:00

#193 Write a test that validates Pixelfed credentials are indeed valid

Niols referenced this issue

2025-02-28 11:08:00 +01:00

Inject initial user in Pixelfed service #215

kiara referenced this issue

2025-03-18 09:24:53 +01:00

expose initialUser choices to the user #250

kiara added this to the Fediversity project

2025-03-18 09:25:41 +01:00

kiara commented

2025-03-18 11:12:22 +01:00

Author

Owner

as a workaround until this story, a dummy value is passed

as a workaround until this story, a [dummy value](https://git.fediversity.eu/Fediversity/Fediversity/commit/6275e8b2dc1e7dd4091e9f2d1bb58a9f2acab09d#diff-de06c10854bd6e90e4d3acc5f00f0c1fdbb89a00) is passed

fricklerhandwerk referenced this issue

2025-03-18 18:37:46 +01:00

trigger nixops from panel #253

kiara commented

2025-03-19 16:40:17 +01:00

Author

Owner

@kevin noted we may be able to pull these from the django auth info

👍 1

kiara referenced this issue

2025-03-23 09:46:40 +01:00

Wire up passing credentials from FediPanel to the Mastodon configuration #189

kevin commented

2025-03-28 13:58:21 +01:00

Owner

I looked at what info you can get from the django auth and.

we can get the username and email from django. But for the password we cant since django uses 1 way hashing and thus its impossible to get the password from django. so we need find a create a way to have the operator specify that themself when the configure the services

I looked at what info you can get from the django auth and. we can get the username and email from django. But for the password we cant since django uses 1 way hashing and thus its impossible to get the password from django. so we need find a create a way to have the operator specify that themself when the configure the services

👍 1

kiara commented

2025-03-31 09:10:15 +02:00

Author

Owner

have a password field in the form (potential security risk, viable at most for demo purposes);
have the passwords generated rather than user-specified, then present to the user, potentially with the advice to change them (least advisable long-term, as storing/presenting them and relying on user behavior would make for additional attack vectors);
use generated passwords we neither store nor show the user but would then have them use the 'forgot password' function to reset;
long-term: have them hooked into an SSO (#212) so we don't need to generate application-specific users.

we should prob discuss our options here to build some consensus.

@kevin makes sense. i guess with the declarative approach of our form putting it in the form kinda sucks too, as it would then remain exposed. that maybe seems like a broader challenge in our approach we should further consider, to e.g.: - have a password field in the form (potential security risk, viable at most for demo purposes); - have the passwords generated rather than user-specified, then present to the user, potentially with the advice to change them (least advisable long-term, as storing/presenting them and relying on user behavior would make for additional attack vectors); - use generated passwords we neither store nor show the user but would then have them use the 'forgot password' function to reset; - long-term: have them hooked into an SSO (#212) so we don't need to generate application-specific users. we should prob discuss our options here to build some consensus.

👍 1

fricklerhandwerk commented

2025-03-31 09:12:41 +02:00

Owner

Showing once and adding a note to use "forgot password" for a reset sounds reasonable.

👍 1

kiara removed this from the Fediversity project

2025-04-14 11:12:31 +02:00

kiara added the

type

user-story

label

2025-05-01 12:01:15 +02:00

kiara referenced this issue

2025-05-28 14:46:12 +02:00

initial focus on single application for development #327

kiara commented

2025-06-02 09:28:37 +02:00

Author

Owner

out of scope for now as per #327

kiara closed this issue

2025-06-02 09:28:37 +02:00

kiara commented

2025-09-14 13:01:50 +02:00

Author

Owner

our implementation now only creates an initial user, i.e. does not account for changes to the user or password.

our [implementation](https://git.fediversity.eu/Fediversity/Fediversity/src/branch/main/services/fediversity/pixelfed/default.nix) now only creates an initial user, i.e. does not account for changes to the user or password.

~~kiara referenced this issue 2025-09-14 13:17:01 +02:00~~

Wire up passing credentials from FediPanel to the Peertube configuration #191

kiara reopened this issue

2025-09-14 13:18:18 +02:00

kiara referenced this issue

2025-12-02 20:00:49 +01:00

Wire up passing credentials from FediPanel to the Peertube configuration #191

kiara added the

points

label

2025-12-02 23:57:32 +01:00

kiara referenced this issue