Wire up passing credentials from FediPanel to the Pixelfed configuration #190
Labels
No labels
0 points
0.5 points
1 point
13 points
2 points
21 points
3 points
34 points
5 points
55 points
8 points
api service
blocked
component: fediversity panel
component: nixops4
documentation
estimation high: >3d
estimation low: <2h
estimation mid: <8h
infinite points
productisation
project-management
question
role: application developer
role: application operator
role: hosting provider
role: maintainer
security
technical debt
testing
type unclear
type: bug
type: deliverable
type: key result
type: objective
type: task
type: user story
user experience
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Blocks
#178 admin accounts provisioned for deployed services
fediversity/fediversity
#193 Write a test that validates Pixelfed credentials are indeed valid
fediversity/fediversity
Reference
fediversity/fediversity#190
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
initialUserchoices to the user #250as a workaround until this story, a dummy value is passed
@kevin noted we may be able to pull these from the django auth info
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
@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.:
we should prob discuss our options here to build some consensus.
Showing once and adding a note to use "forgot password" for a reset sounds reasonable.
out of scope for now as per #327
our implementation now only creates an initial user, i.e. does not account for changes to the user or password.
kiara referenced this issue2025-09-14 13:17:01 +02:00