You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of now, DTaaS uses https://gitlab.com as an OAuth provider, which works with no problems.
With the ongoing effort to switch to an integrated GitLab instance (#892), if a DTaaS server is set up at http://site.com (note: http and not https) the local gitlab instance would be available at http://site.com/gitlab. However, the homepage "sign in with GitLab" button redirects to https://site.com/gitlab because of a known issue with oidc-client-ts that automatically uses https.
This might even break development servers at http://localhost for the same reason - I'll try it out and post it here.
The text was updated successfully, but these errors were encountered:
Worth noting: Having OAuth on http kind of breaks the purpose of having authentication in the first place, as network requests aren't encrypted anymore. The most likely use case for this would be when you're setting up a DTaaS server and you haven't enabled TLS for your domain yet. Perhaps we could offer a setup option for the server to use gitlab.com instead of the path prefixed local instance?
As of now, DTaaS uses
https://gitlab.com
as an OAuth provider, which works with no problems.With the ongoing effort to switch to an integrated GitLab instance (#892), if a DTaaS server is set up at
http://site.com
(note: http and not https) the local gitlab instance would be available athttp://site.com/gitlab
. However, the homepage "sign in with GitLab" button redirects tohttps://site.com/gitlab
because of a known issue withoidc-client-ts
that automatically useshttps
.This might even break development servers at
http://localhost
for the same reason - I'll try it out and post it here.The text was updated successfully, but these errors were encountered: