I set up several tests using the zrok frontdoor service (zrok.io) as follows:
- OAuth (google) settings:
*@myworkemail.com
- OAuth (google) settings:
mypersonalemail@gmail.com
- OAuth (github) settings:
mypersonalemail@gmail.com
Number one worked without a hitch, and as a test my co-worker was able to sign in with their email and access the web service too. However the tests with my personal email consistently return the zrok "unauthorized" page. I'm guessing this is related to the use of the gmail.com domain or the lack of wildcard character?
Where could I look to more details or logs on this issue?
Thanks,
T
I tested successfully with my personal @gmail.com login. I suspect your browser may have state for multiple Google accounts. Do you get the same result with an incognito/private tab?
When it wasn't working, had you specified multiple patterns like this?
zrok reserve public --oauth-provider google --oauth-email-address-patterns my.personal.email@gmail.com --oauth-email-address-patterns my.other.personal.email@gmail.com
Or was it only a single pattern? I'm asking because if multiple patterns exist, they must be set with separate flags in the same command, not a comma-or-space-separated list.
I tried incognito, safari, chrome, clearing cookies, still unauthorized.
I'll look at the logs when I'm back with my computer to see the full zrok command, but I do know that I specified a string like so:
1: ZROK_OAUTH_EMAILS="*@myworkemail.com"
2/3: ZROK_OAUTH_EMAILS="mypersonalemail@gmail.com"
in zrok-share.env for frontdoor
T
1 Like
Cool, thank you. Are you running the zrok-share package version 0.4.26? In that latest version (link to release notes), I changed the command line to match the new flag --oauth-email-address-patterns introduced in zrok 0.4.25 that matches the pattern as a glob.
Before 0.4.25, zrok used the flag --oauth-email-domains and matched on trailing characters.
You can check the zrok controller version like this to see which form is expected by your zrok instance.
❯ curl -sf https://api.zrok.io/api/v1/version
"v0.4.26 [f1c9f11e]"
Hey, here is the command that the zrok-share package is running after reading my zrok-share.env:
zrok reserve public --json-output --unique-name pm4control --backend-mode proxy http://127.0.0.1:80 --oauth-provider github --oauth-email-address-patterns 'tristanryerparke@gmail.com'
Controller version is:
"v0.4.26 [f1c9f11e]"
I'm still getting the 'unauthorized' error on incognito and normal tabs.
T
I have a hypothesis, but it seems like a long shot. Maybe the canonical form of your GMail mailbox address has stop characters (period .)? I expected the normalized form to be stripped of periods and any suffix including the + character, but maybe your "real" GMail address has periods in it?
If so, that's the same form you must use in the email address pattern, even though GMail.com ignores . characters in the prefix@ for mailbox and Google Groups distro addresses.
Both tristanryerparke@gmail.com and tristan.ryer.parke@gmail.com are treated as aliases by GMail, but only the form that shows up in your Google account info will match the email address pattern.
For example, if my GMail mailbox name is "acmeboxen" and I set a pattern like --oauth-email-address-patterns acme.boxen@gmail.com then I'll unauthorized.
I'm having this same issue with frontdoor OAuth.
I've only tried using github as the OAuth provider, and I have not tried wildcarding anything, only an explicit email address. I am also using a gmail.com address. I only have one email address specified for ZROK_OAUTH_EMAILS, so I don't think it's an issue of multiple patterns or incorrectly separated patterns in the variable.
Like twisteddog, I also tried incognito, different browsers, clearing cookies, etc. and still see the Unauthorized splash page each time.
The canonical form of my email address doesn't have stop characters in it, only alpha characters.
My output for version is:
$ curl -sf https://api.zrok.io/api/v1/version
"v0.4.26 [f1c9f11e]"
I'm happy to dig into this to try and figure it out. Are there logs I can be providing that would be helpful?
EDIT:
One thing I just thought of is that I do have multiple emails associated with my github account, and the secondary email does have stop characters in it. My primary email does not though.
Welcome @craig-cogdill, and thanks for those details. I believe that GitHub's OAuth2 flow always uses the primary email address. Logging in with GitHub will only work if the allowed email address pattern in your zrok command matches the primary email on your GitHub.com account.
link to GitHub profile settings
❯ gh api graphql -f query='
query {
user(login: "mygithubhandle") {
email
}
}'
{
"data": {
"user": {
"email": "my@primary.example.com"
}
}
}
@qrkourier Where could I look for logs related to my "unauthorized" issue?
I've switched to basic auth for the time being but would prefer to figure out why oauth is not working, and solve the problem.
Best,
T
I think you're trying to use GitHub Oauth with a zrok.io public share.
I suspect that you're logging in with an email address other than the primary email on your GitHub.com account.
Please check which one is marked "primary" in Sign in to GitHub · GitHub
Your public share backend won't show any logs unless Oauth succeeds. Those logs are emitted by the zrok frontend which is hosted by zrok.io in this case, if I understood correctly.
I'm having the same problem using frontdoor. I have the following lines in zrok-share.env,
ZROK_OAUTH_PROVIDER="google"
ZROK_OAUTH_EMAILS="*@lassio.io"
I also tried several browsers, cleared cookies, tried incognito. I suspected that it was a problem with reusing a previously reserved share, but the same problem happens with a newly provisioned random share. No auth and basic auth both work as expected.
This is reserve command being issued,
zrok reserve public --json-output --backend-mode proxy http://localhost:3000 --oauth-provider google --oauth-email-address-patterns '*@lassio.io'
I'm running v0.4.30 [96bfe62c] on Ubuntu LTS.
Hey @stefanadelbert and welcome to the OpenZiti (and zrok) community.
In your example, does the Google account that you're logging in with have a primary email address that matches the *@lassio.io pattern?
After changing the pattern to match my work account, I authenticated with my Google account to a reserved public share I created with the same command. I used the public zrok.io instance to test..
Hi @qrkourier Thank you for the reply and for taking the time to test this on your side.
I am definitely using an email account where the email address matches the pattern. I've tried various forms of the pattern too (@lassio.io, *@lassio.io, *lassio*, complete email address) all with the same result. Below are the relevant journal entries for one of the configurations,
Jun 03 23:15:36 instance-1 systemd[1]: Starting zrok reserved public share service...
Jun 03 23:15:36 instance-1 zrok-enable.bash[1783227]: INFO: zrok environment is already enabled. Delete '/var/lib/private/zrok-share/.zrok/environment.json' if you want to create a new environment.
Jun 03 23:15:36 instance-1 systemd[1]: Started zrok reserved public share service.
Jun 03 23:15:36 instance-1 zrok-share.bash[1783232]: DEBUG: ZROK_SHARE_RESERVED=true
Jun 03 23:15:36 instance-1 zrok-share.bash[1783232]: INFO: reading share configuration from /opt/openziti/etc/zrok/zrok-share.env
Jun 03 23:15:36 instance-1 zrok-share.bash[1783232]: INFO: validated backend mode proxy and target http://localhost:3000
Jun 03 23:15:36 instance-1 zrok-share.bash[1783232]: INFO: running: zrok reserve public --json-output --backend-mode proxy http://localhost:3000 --oauth-provider google --oauth-email-address-patterns '*lassio*'
Jun 03 23:15:38 instance-1 zrok-share.bash[1783232]: INFO: zrok public URLs: ["https://zlne4gaoa4o4.share.zrok.io"]
Jun 03 23:15:38 instance-1 zrok-share.bash[1783232]: INFO: running: zrok share reserved zlne4gaoa4o4 --headless --override-endpoint http://localhost:3000
Jun 03 23:15:39 instance-1 zrok-share.bash[1783232]: [ 1.029] INFO main.(*shareReservedCommand).run: sharing target: 'http://localhost:3000'
Jun 03 23:15:39 instance-1 zrok-share.bash[1783232]: [ 1.029] INFO main.(*shareReservedCommand).run: using existing backend proxy endpoint: http://localhost:3000
Jun 03 23:15:40 instance-1 zrok-share.bash[1783232]: [ 2.329] INFO sdk-golang/ziti.(*listenerManager).createSessionWithBackoff: {session token=[9d73842d-4fe1-4bd2-b7d5-ad962998b2ed]} new service session
Jun 03 23:15:41 instance-1 zrok-share.bash[1783232]: [ 2.647] INFO main.(*shareReservedCommand).run: access your zrok share: https://zlne4gaoa4o4.share.zrok.io
I also tried using pattern *@gmail.com, but I got the same failure.
I have just tried commenting out ZROK_OAUTH_EMAILS from zrok-share.env, but leaving ZROK_OAUTH_PROVIDER="google" in place and then reserving a new (random) frontend URL. I was able to authenticate and access my backend proxy without problem.
Which pattern matching methodology is used for the patterns, as a matter of interest?
Any other thoughts on what I might be able to try here?
Everything works exactly as expected if I run these commands directly as non-root,
zrok enable <TOKEN>
zrok reserve public --json-output --backend-mode proxy http://localhost:3000 --oauth-provider google --oauth-email-address-patterns '*@lassio.io'
zrok share reserved vxt96epb95gy --headless --override-endpoint http://localhost:3000
I copy-pasted those from the journal, i.e. they are what frontdoor is supposedly running.
Could it be something that frontdoor is doing differently behind the scenes?
You're right, the pattern had one too many escapes when it ran the zrok reserve public command. 
Sorry about that. Thank you for helping me find the problem.
Here's the patch. You can apply it like this:
sudo patch /opt/openziti/bin/zrok-share.bash < /tmp/patch
Since you already have a reservation, you must do two things to replace it:
- In the console, delete the share
- Delete
/var/lib/zrok-share/.zrok/reserved.json to allow the service to reserve a new share
diff --git a/nfpm/zrok-share.bash b/nfpm/zrok-share.bash
index d79db5d7..a0480d3d 100644
--- a/nfpm/zrok-share.bash
+++ b/nfpm/zrok-share.bash
@@ -133,7 +133,7 @@ if [[ -n "${ZROK_OAUTH_PROVIDER:-}" ]]; then
ZROK_CMD+=" --oauth-provider ${ZROK_OAUTH_PROVIDER}"
if [[ -n "${ZROK_OAUTH_EMAILS:-}" ]]; then
for EMAIL in ${ZROK_OAUTH_EMAILS}; do
- ZROK_CMD+=" --oauth-email-address-patterns '${EMAIL}'"
+ ZROK_CMD+=" --oauth-email-address-patterns ${EMAIL}"
done
fi
elif [[ -n "${ZROK_BASIC_AUTH:-}" ]]; then
1 Like
Nice one, @qrkourier! I confirm that this fix works.
1 Like