Syndesis: Can't login with Firefox < 61.0b13

Created on 30 Jul 2019  路  13Comments  路  Source: syndesisio/syndesis

This is a Bug report/probable regression


[ ] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ X ] Bug report  
[ ] Documentation issue or request

Description

I'm trying to login to Syndesis using the default OAuth in Firefox 60.8.0esr (64-bit) (default version on Debian stable/buster). But a CORS error makes the config.json request to fail:

imagen

This is not reproducible since Firefox v61.0.b13 due to implementation of the updated spec:

By default, fetch won't send or receive any cookies from the server, resulting in unauthenticated requests if the site relies on maintaining a user session (to send cookies, the credentials init option must be set).
Since Aug 25, 2017. The spec changed the default credentials policy to same-origin. Firefox changed since 61.0b13.

I suggest modifying the fetch call to explicitly add the cookies:

imagen

imagen

cabug ignorqe prip1

All 13 comments

Did you by running this first?

oc patch dc syndesis-ui --type json --patch "[{\"op\": \"replace\",
\"path\": \"/spec/template/spec/containers/0/volumeMounts/0/mountPath\",
\"value\": \"/opt/app-root/src/config\"}]"

Not related, this is a problem on the frontend.

The same deployment works on Chromium.

Not sure, but I had the same problem in the past on both Chrome and Firefox and with that command I was able to see the ui again.

It appears that this change:

https://github.com/syndesisio/syndesis/blob/9628b0a6dbbabb5f75488e6cbde7ba627d3535bf/install/generator/04-syndesis-oauth-proxy.yml.mustache#L102

is not in the the templates the operator uses:

https://github.com/syndesisio/syndesis/blob/3b5ecb2fdaac1005cf008acda155235f69636444/install/operator/pkg/generator/assets/install/04-syndesis-oauth-proxy.yml.mustache#L69-L74

We're running more and more into issues when those two templates differ.

And this is not a CORS issue, we're running against the same domain.

Firefox is an evergreen browser, thus we support only the latest (major) version. Last stable version is 68.0.1, so we can support 68.0.x.

That said, I think @oscerd's got a point. The config.json file is a virtual file served by the UI pod and it's whitelisted from having to be accessed by a logged-in user. That oc patch is somehow related to this change for reasons I don't know/recall. Does it happen on FF in private browsing too?

Anyhow as I said we can't really support FF v60.x.

Uhm I just learned that ESR is a version numbering that doesn't map the official versioning, so Firefox 60.8 esr is actually the current stable. I guess you can dump the "we don't support that" part of my previous comment :D

I'd still check out the patch bit because it really seems like there is something gone bad in the install process. By the way, we always include credentials (cookies) with our fetch calls.

Interestingly, I do have the same problem with FF 60.8 esr (which I happened to have automatically installed on my machine), but not with FF 69.

Not sure why it's happening, but it shouldn't happen; the config.json should be open for everybody. Is that route patched on staging, anyone?

Technically, config.json is open. But on FF<61 it is not sending the proper cookies, so you get a redirection to oauth.

Which shouldn't happen because of this line.

@Delawen Has this been resolved?

If something is fixed on syndesis-staging server, the bug is still there. Where should I test this? (Testing in local is not very trustable yet :D)

With ./syndesis minishift --install actually the config.json is not accessible.

So if you curl it from terminal you'll get

oscerd@ghost:~/workspace/jboss-fuse/syndesis$ curl -k https://syndesis.192.168.99.100.nip.io/config.json <a href="https://192.168.99.100:8443/oauth/authorize?approval_prompt=force&amp;client_id=system:serviceaccount:myproject:syndesis-oauth-client&amp;redirect_uri=https://syndesis.192.168.99.100.nip.io/oauth/callback&amp;response_type=code&amp;scope=user:info+user:check-access&amp;state=702afe76b4b43ec354461bde2f4705c7:/config.json">Found</a>.

The whitelisting doesn't work and the patch workaround is not actual anymore.

Was https://github.com/syndesisio/syndesis/issues/6282#issuecomment-516429726 not seen? The operator bits are missing the configuration needed to fix this.

Was this page helpful?
0 / 5 - 0 ratings