SUMMARY
integration/__main__.py is a CLI-based HTTP client that can interact
with Hostea Dashboard and Gitea.
Integration tests are run via integration/tests.sh, which is a
driver for the HTTP client at integration/__main__.py. The script is
capable of spinning up a test environment consisting of services
defined in docker-compose-dev-deps.yml and the Hostea Dashboard and
tearing it down after a successful run.
The credentials used to create various accounts and other parameters
are all defined in integration/tests.sh script it self. So it is
self contained.
CLIENT FUNCTIONALITY:
HOSTEA DASHBOARD:
- register user with email verification
- login
- create OIDC app
- visit support page
GITEA:
- Install Gitea(DB configuration, etc. The first form that's
presented to the visitor after a new instance is deployed)
- Register User
- Login User
- Create repository
- Configure OIDC SSO
- Login via SSO
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
Aravinth Manivannan
Loïc Dachary