Use squidex API endpoint with local network name inside docker

I have…

I’m submitting a…

  • [x] Regression (a behavior that stopped working in a new release)
  • [ ] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

I a have some web app which consume API from squidex. To make it faster and avoid round trip thru cloudflare (in our case) i use docker name as url endpoint for squidex client. This worked well until the last upgrade to 6.6.0. Now i got this error:

System.Security.SecurityException: Failed to retrieve access token for client 'xxx', got HTTP InternalServerError - Method: POST, RequestUri: 'http://squidex_squidex/identity-server/connect/token', Version: 1.1, Content: System.Net.Http.StringContent, Headers:
  Request-Id: |036436b9d237d6a57b323d58eb9148eb.d226f05ab0d33b5f.
  traceparent: 00-036436b9d237d6a57b323d58eb9148eb-d226f05ab0d33b5f-00
  Content-Type: application/x-www-form-urlencoded; charset=utf-8
  Content-Length: 136
} for url http://squidex_squidex/identity-server/connect/token

Expected behavior

Is this expected change?


  • [x] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ ] Cloud version

Version: 6.6.0

I use nswag to generate api inspired with official sdk with similar IAuthenticator as official sdk.

Log from server, not sure if it relevent.

Honestly, I have no idea what this is.

But what you have configured as base url?

base url is standart as

I see. So it happens when you have different URLs,

Client A connects to squidex_squidex
Client B connects to

Right ?

It happens only when i connect to squidex_squidex (which is container name).

If i connect to bash inside my app container (not the one which runs squidex but, the one which runs application consuming squidex API).

And when i call:
curl -X POST -d 'grant_type=client_credentials&client_id=xxx&client_secret=xxx&scope=squidex-api' http://squidex_squidex/identity-server/connect/token

I got:

<!DOCTYPE html>
    <base href="/">

    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">

    <title>Error - Squidex Headless CMS</title>

    <link rel="stylesheet" href="/styles.css" />

<body class="profile">
    <div class="profile-container">
        <img class="profile-logo" alt="Squidex Headless CMS" title="Squidex Headless CMS" src="/images/logo.svg" />

        <div class="profile-card card">
            <div class="profile-card-body card-body">

<img class="splash-image" src="/squid.svg?title=OH%20DAMN&amp;text=I%20am%20sorry%2C%20that%20something%20went%20wrong" />

<h1 class="splash-h1">Operation failed</h1>

<p class="splash-text">
        <span>We are really sorry that something went wrong.</span>

        <div class="profile-footer text-center mt-4 mb-2">
            <small class="text-muted">
                Proudly made by<br />Sebastian Stehle and Contributors, 2016-2021

If i make the same call but instead of container name use actual domain which is used to host squidex.

curl -X POST -d 'grant_type=client_credentials&client_id=xxx&client_secret=xxx&scope=squidex-api'

I got valid token.

  "access_token": "exxxx",
  "token_type": "Bearer",
  "expires_in": 2591999,
  "scope": "squidex-api"

It is related to this issue:

I had to use absolute URLs to get it working.

Perfect basically it means that there have to be use endpoint with same domain name as set via URLS__BASEURL if I understand conservation of the issue correctly.

Yes, but let me try something.

1 Like

I have pushed a potential fix. Lets see if the build goes through.

Can you try dev-6793 ?

It seems working at least from quick test with curl against fresh new squidex container.

1 Like

I will make a final fix and introduce an option for that, because with this change the issuer url would change and all tokens would become invalid.

1 Like

Okay, it is pushed. You have to set IDENTITY__MULTIPLEDOMAINS=true

Should I test the identity-server/connect/token or have I before upgrading save some token or do anything else?

Yes, just test if this endpoint works for you.

With dev-6794 it looks like it does not work (i test it as upgrading previously created container and use curl from another container)

Have you set the environment variable?

oh, sorry i forgot about it, my bad. It works well. Do you plan to publish this as “stable” docker image?

Yes, but I don’t know when. Perhaps this friday.

1 Like

That would be great thank you for fast response as always :slight_smile:

1 Like