Dashboard apps: does it also support making POST-calls?

[VSinghhh]

Right now dashboard apps shows that it can retrieve/GET information about orders etc.
But our sender wants to 'cancel' order: is it possible for us through chatwoot to make a POST-call to our system to cancel an order, for example?

[antoniomdk]

The dashboard app is basically an iframe, so you can have any web app that makes post requests to another server. For example, I have a NextJS (+ NextAuth) app deployed in Vercel with basic user/pass auth and cross-domain cookie policies. From the UI I just call the API routes and from those routes, I interact with the other service (Woocommerce).

I personally use NextJS with NextAuth, but you can use any web app as long as it has some layer of authentication or firewall restrictions that make it only accessible to your senders.

[VSinghhh]

Thank you for the prompt reply!
For ease I'll use the words 'agents' for those inside chatwoot, and 'customer' for those emailing us,

1. You mean only accessible to our agent(by the word "senders") - i.e not the customers who emails us?

2. Does the agent need to input basic user/pass when accessing the app or is that sent in the cross-domain cookie policy?

3. So essentially the flow is:
   A. We receive an email in chatwoot ("order cancellation")
   B. We click on the dashboard app and it opens our webapp in an iframe and sends in the order number from the email?
   C. We click to cancel inside the iframe?

The question marks being the part that I'm confused about :)

[antoniomdk]

1. Yes, the web app should only be accessible to your agents, because I'm assuming they are the one that have the final word on if an order is canceled or not and they trigger the action.

2. There are several ways of protecting the access of your web app to only be accessible by the agents. You can have a user/pass that needs to be typed every time (e.g a basic HTTP auth middleware), or you can use cookies to store the session data, so agents only need to type the credentials once. The problem with iframes is that your web app lives on another host, so you either deploy the web app in the same domain (only possible if you self-host chatwoot), or enable cross-domain cookies. You can start with a basic auth, and then exploring the cookies options, depending on how many cancellation requests you're getting. The other alternative I mention is that if you know your agents IPs or their machines are under a VPN, you can expose the webapp to those IPs only.

3. The flow is correct. You can get fancy in the web app and collect the list of orders from the customer information that is sent via window (as chatwoot docs states) and show a table or something, but that's up to you.

[antoniomdk]

btw, I can put together a small Next-NextAuth boilerplate for Chatwoot and share it with you if that's something you'd be interested in.

[VSinghhh]

That would be super appreciated!

Btw we will be going with self-hosted chatwoot :)

[antoniomdk]

I'll try to put together the repo late today or tomorrow :)

[VSinghhh]

Really appreciate that :)

[antoniomdk]

https://github.com/antoniomdk/chatwoot-app-example

This is an example. It protects all pages with a basic user/pass and stores the session in the cookie. If you are deploying in the same domain as chatwoot, then you can use sameSite="lax" in the cookie config. This is just one way of protecting your chatwoot app. But you can explore other options if you don't want to use next or next-auth.

One alternative is to use an Nginx reverse proxy with HTTP basic auth.. All of the alternatives I'm mentioning do not provide good security measures, but it is better than just exposing your web app to the world.

If you use Okta, Keycloak, or any other type of OAuth authentication in your company, you can use oauth2-proxy.

[VSinghhh]

Super super appreciate it Antonio! This is a great start for us to test this with!

…

2 mars 2023 kl. 15:29 skrev Antonio Molner Domenech ***@***.***>: https://github.com/antoniomdk/chatwoot-app-example <https://github.com/antoniomdk/chatwoot-app-example> This is an example. It protects all pages with a basic user/pass and stores the session in the cookie. If you are deploying in the same domain as chatwoot, then you can use sameSite="lax" in the cookie config. This is just one way of protecting your chatwoot app. But you can explore other options if you don't want to use next or next-auth. One alternative is to use an Nginx reverse proxy with HTTP basic auth. <https://siddharthac6.medium.com/nginx-implementing-basic-authentication-ecc1100c3a3c>. All of the alternatives I'm mentioning do not provide good security measures, but it is better than just exposing your web app to the world. If you use Okta, Keycloak, or any other type of OAuth authentication in your company, you can use oauth2-proxy. <https://oauth2-proxy.github.io/oauth2-proxy/> — Reply to this email directly, view it on GitHub <#6543 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEQ7DKYL6EGRYIDZOVSWF3W2CVGDANCNFSM6AAAAAAVHZSXLE>. You are receiving this because you authored the thread.