<moz_arc>
so I'm having a strange issue getting OAuth working during the setup flow for Sandstorm
<moz_arc>
Whenever I try to sign into Github to create the admin account, I get kicked right back to the "choose an OAuth provider" screen
<moz_arc>
hello - anyone here?
<simpson>
I'm here but have no idea how to answer your question. Sorry.
<moz_arc>
lol, that's fine
<moz_arc>
I posted an issue on the Github repo but I haven't gotten a response in a couple days so I figured I'd hop onhere
<moz_arc>
on here*
<kentonv>
moz_arc, by any change did you enable the "disallow collaboration with people outside the organization" option?
<moz_arc>
nope, lol, that's what you said on my github issue too
<kentonv>
oh, that's usually the reason, hmm
<moz_arc>
for more context; I'm running it on Arch Linux, and using Nginx as a proxy
<kentonv>
seemingly the login is failing. Do you see anything in the log? /opt/sandstorm/var/log/sandstorm.log
<moz_arc>
Cloudflare wildcard cert for the subdomain
<moz_arc>
lemme take a look
<kentonv>
note that Cloudflare won't actually proxy a wildcard unless you have an enterprise account, and if it's not proxying then it's not giving you a certificate -- but this is probably not related to your login issue
<moz_arc>
hmm
<moz_arc>
no, I mean the proxy is local
<moz_arc>
i.e. the Sandstorm server is at 127.0.0.1:6080
<kentonv>
maybe you meant Cloudflare wildcard DNS, not "wildcard cert"?
<moz_arc>
how could Cloudflare tell that I'm running Nginx and locally proxying
<moz_arc>
functionally speaking, what difference does it make?
<kentonv>
you said "Cloudflare wildcard cert for the subdomain" -- what did you mean?
<moz_arc>
I have a Cloudflare cert for my domain, that I believe is a wildcard cert
<kentonv>
but Cloudflare only gives you a cert if you're using them as a proxy
<kentonv>
it supports wildcard DNS but won't actually act as a proxy for the wildcard, unless you are an enterprise customer.
<moz_arc>
I see
<moz_arc>
def not an enterprise customer, I'm just some random scrub setting up a server in his bedroom
<kentonv>
yeah, for non-enterprise, the DNS entry will just point to your origin IP
<moz_arc>
that's OK, I have a let's encrypt cert (which is non-wildcard...)
<kentonv>
unfortunately, sandstorm requires a real wildcard...
<kentonv>
but you could configure your browser to trust it
<moz_arc>
is there such a thing as a free wildcard cert?
<kentonv>
not yet. Let's Encrypt is supposed to support it soon.
<kentonv>
well, we give out free wildcards for sandcats.io
<moz_arc>
allegedly Feb. 28th...
<moz_arc>
ah fun
<kentonv>
anyway
<moz_arc>
I'll just nuke the server and reinstall to get a sandcats.io domain
<kentonv>
none of this is related to your login problem
<moz_arc>
no, but it's good informatio
<moz_arc>
information*
<moz_arc>
is it possible to use nginx as a reverse-proxy with sandcats.io?
<kentonv>
it's tricky because you have to get nginx to use the sandcats cert which is replaced weekly, but there was someone who did it and wrote a blog post about it...
<moz_arc>
this tutorial really seems to suggest that I should dockerize it
<kentonv>
I guess you can do that though IMO it's weird to run a container engine inside another container engine... :)
<moz_arc>
yeah, a bit meta
<kentonv>
regarding the login issue, it might be some sort of configuration disagreement about your URL
<moz_arc>
seems like more trouble than it's worth to get it reverse-proxied as it would entail killing my Nginx process an dmessing with iptables
<moz_arc>
I suppose I'll just wait until letsencrypt starts handing out wildcard certs at the end of february then drop cloudflare
<moz_arc>
because otherwise my Sandstorm server can't actually run any grains, correct?
<kentonv>
you could still use cloudflare for DNS, but yeah, it won't give you wildcard SSL coverage
<kentonv>
and yeah, you need the wildcard to actually run apps
<moz_arc>
which prevents me from connecting to subdomains with SSL... which I really want.
<moz_arc>
for now I'll set up syncthing to achieve the same goals, at least temporarily
<kentonv>
in your sandstorm.conf, is your BASE_URL configured to http:// or https://?
<moz_arc>
http
<kentonv>
but in your browser you're actually entering https, right? because of the proxy?
<moz_arc>
this is for the sandcats.io domain
<kentonv>
oh you've already wiped and started over?
<moz_arc>
I'm essentially dropping the whole thing for now, since there's no way to actually get it to work in my situation (no wildcart cert, so no HTTPS)
<moz_arc>
and I don't trust anything that's not over HTTPS with my data
<kentonv>
ok. Well for the record, the OAuth issue could have been because you had BASE_URL=http:// but you were actually accessing over https... the BASE_URL should match whatever is typed into the browser.
<moz_arc>
mm that makes sense
<kentonv>
unfortunately mismatching URLs tend to make OAuth fail silently
<kentonv>
(the URL configured on the Google/Github side also has to match what's seen in the browser)
<moz_arc>
otherwise that's an auth mismatch which could be malicious
<moz_arc>
makes sense that it'd get dropped in that case