STEPS
1. Register new user on dashboard
2. Confirm user email, link is received from email. maildev/maildev
is an SMTP server specifically built for testing emails locally.
It comes with a REST API[0], which is used to access emails
3. Sign in to Dashboard
4. Visit /support/new/ on dashboard to raise new support request
5. Redirection to Hostea Gitea support repository is done via
JavaScript, so we simply test to see if the support repository's
new issue page is present in the Dashboard response
6. Go to support repository's new issue page. Gitea will redirect to
sign in page
7. Parse sign in page, find OIDC SSO link in sign in page
8. Visit OIDC SSO link in sign in page, to be redirected to
authorization page
9. If OIDC integration on Dashboard is setup via `create_oidc`
management command, then auto-authorization will be enabled for
the integration. So user will be redirected to Gitea
10. For new OIDC logins, Gitea will present a form to choose
preferred username and enter email address. So fill that form
and submit it.
Please note the form submits to a different URL than the one at
which the form is available. See `Gitea.__link_acount` and
`Gitea.__link_acount_signup` and its usage in `Gitea._sso_login`
11. Verify user creation by GET /{username}, should respond HTTP 200
12. Visit new issue on support repository, should respond HTTP 200
RESOURCES
[0]: https://github.com/maildev/maildev/blob/master/docs/rest.md
My env var loading technique is not allowing local_settings.py to
override settings.py. This hotfix disables env vars in favor of
local_settings.py.
fixes https://gitea.hostea.org/Hostea/dashboard/issues/3
> Django’s internationalization hooks are on by default, and that means
there’s a bit of i18n-related overhead in certain places of the
framework. If you don’t use internationalization, you should take the
two seconds to set USE_I18N = False in your settings file. Then Django
will make some optimizations so as not to load the internationalization
machinery. # Please enter the commit message for your changes. Lines
starting
ref: https://docs.djangoproject.com/en/4.0/topics/i18n/translation/
SUMMARY
PAYMENT WORKFLOW
1. User is redirected after a new instance is created into a view
that generates invoice. There are checks in place to ensure
invoices are not generated twice for the same VM. There is also a
check in place to generate invoices for time periods that are
already paid for
2. User is redirected to payment form
3. Stripe takes over
4. If payment is successful, user is redirected to success page
5. If payment failed, user is redirected to failure page
PENDING INVOICES
The user can see pending invoices on their dashboard
PAYMENT RECEIPTS
The user can see payment receipts on their dashboard
DESCRIPTION
Some views are privileged and unauthorized execution can have
irreversible changes. confirm_access decorator checks if the user's
session is verified for privileged operation execution.
If not, it will redirect user to "accounts.sudo" vie" vie" vie" view
Aravinth Manivannan
Loïc Dachary