API - Add allowed origin on self-hosted Zammad Server

[jmayer]

Hello,
I’m currently implementing the Zammad API into a SaaS-Solution. Basically I want to automatically create a ticket or note, when an exception occurs for a user.

I need a possibility to add allowed origins since the Zammad-Env has its own hosted Server.

I already tried to add the “Access-Control-Allow-Origin” Header in the zammad nginx configuration but that didn’t work unfortunately.

I would be very thankful for some advices.

[jmayer]

I was able to narrow the problem down further. The Browser sends the Authorization header in the preflight OPTIONS request aswell. This doesnt succeed since it has the auth header with it. Because the preflight failed the actual POST didn’t go through.

Does anyone know what to do so that the preflight excludes the auth header?

[thorsteneckel]

Hi @jmayer - welcome to the community!

Zammad sends the Access-Control-Allow-Origin – but not for Token or BasicAuth. How is your authentication implemented?

[jmayer]

I wanted to use the token authentication. So I have to switch to OAUTH?
The SaaS is a multi-tenant solution. I just want to use one single Zammad Account for the API-created tickets. Is that possible with OAuth?

[MrGeneration]

You don’t have to use OAUTH to do that.
Token based authentication is perfectly fine.

What you seem to be missing is that your Token is not provided via header.
See: https://docs.zammad.org/en/latest/api/intro.html#http-token-authentication-access-token

This might help you.

[jmayer]

@jmayer

preflight OPTIONS request aswell. This doesnt succeed since it has the auth header with it. Because

I’m providing the token in the header (this is typescript):

And it works as you can see here:

Now the error is, that the authorization header isn’t allowed in a OPTIONS request (preflight check from browser):

[thorsteneckel]

Hi @jmayer – as stated earlier:

Zammad sends the Access-Control-Allow-Origin – but not for Token or BasicAuth .

There are two OAuth functionalities available in the Zammad context:

1st) You can authorise via a third party identity provider (such as GitHub, Twitter etc.) which will create a valid HTTP session (cookie based) for you.

2nd) Zammad can act as identity provider (such as GitHub, Twitter, etc.) for third party systems via OAuth to verify that the requesting identity exists.

I don’t think that any of the both listed above will server. your need.
The issue that I see here is that you expose the session of the authenticated user to the browser session. This will enable an attacker to access other endpoints in the name of the used session (changing password, read other tickets, etc.). That’s why this kind of requests is prohibited by measurements we installed namely the Content Security Policy. The CSP will be another roadblock in your way.

Accessing third party system APIs with an authenticated session directly is potentially dangerous and not recommended.

My proposal would be to:

a) use the Form endpoint which does not need any authentication

or

b) create an intermediate API endpoint that encapsulates/handles the authentication and request to the Zammad API (like a wrapper) and exposes a single, dedicated endpoint for POSTing the payloads.

Hope this helps in any way.