mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 16:56:00 +03:00
[GH-ISSUE #91] API CORS #63
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#63
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @alainmaradan on GitHub (Apr 17, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/91
Hi,
I'm writting an app that use the API provided by mailpit and I'm stuck with some CORS issues:
Access to XMLHttpRequest at 'https://mywebsite.com/api/v1/messages?limit=500' from origin 'https://myfrontwebsite.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Is there a way to add those headers in the app ?
Thanks.
@axllent commented on GitHub (Apr 17, 2023):
Hi. I need more information please. Mailpit has very strict headers in order to protect the Mailpit user & application.
What is requesting
https://mywebsite.com/api/v1/messages?limit=500fromhttps://myfrontwebsite.com/- a web browser? If so, then I don't think that will work anyway, as all browsers will block you from loading remote (different host) JSON. That is what JSONP is intended for, however Mailpit doesn't support JSONP.@alainmaradan commented on GitHub (Apr 17, 2023):
Hi, the request is made with Axios on a VueJs app.
It works if I use a chrome extension to allow CORS (https://chrome.google.com/webstore/detail/allow-cors-access-control/lhobafahddgcelffkeicbaginigeejlf) but not without it.
I think the problem exist because no CORS are defined. Maybe it should be possible to specify some CORS in the runtime options ?
@axllent commented on GitHub (Apr 17, 2023):
No problem, that makes sense. I'm trying to research what security implications it would have if I had
Access-Control-Allow-Origin: *always set, as CORS doesn't actually protect the Mailpit server (only from browser requests). If that is not an option, then I can add a commandline / environment flag to set this, but at this point I'm leaning towards the*option. One way or the other, I'll add this feature (or enable it) 👍@LeoniePhiline commented on GitHub (Apr 17, 2023):
Using
*would undo the security.I am just user of mailpit and bystander in this conversation. But if I may add my thoughts, requiring a commandline / environment value for
Access-Control-Allow-Originwould be very much preferable. This way, users could open CORS for their host in addition to the mailpit frontend, while keeping maximum protection.@axllent commented on GitHub (Apr 21, 2023):
I have added this option and released it with v1.6.0. You can now set the CORS with
--api-cors "*"(more info).Please close this issue if it solves your issue, thank you.
@alainmaradan commented on GitHub (Apr 21, 2023):
Thank you for the improvement. No more cors error.
@alainmaradan commented on GitHub (Apr 24, 2023):
Hi,
It seems DELETE method is not allowed:
Access to XMLHttpRequest at 'https://myapp.com/api/v1/messages' from origin 'https://myfront.com' has been blocked by CORS policy: Method DELETE is not allowed by Access-Control-Allow-Methods in preflight response.@axllent commented on GitHub (Apr 24, 2023):
@Mint1700 I have just added this in v1.6.5. Please let me know if this resolves your issue, thanks?
@alainmaradan commented on GitHub (Apr 29, 2023):
@axllent Now the following error shows on delete :
Access to XMLHttpRequest at 'https://myapp.com/api/v1/messages' from origin 'https://myfront.com' has been blocked by CORS policy: Request header field content-type is not allowed by Access-Control-Allow-Headers in preflight response.@axllent commented on GitHub (May 4, 2023):
@Mint1700 I have just release v1.6.6 which adds
Access-Control-Allow-Headers(*) to the API responses. Hopefully this now resolves your issue 🤞@alainmaradan commented on GitHub (May 8, 2023):
Hi, @axllent Thanks for the update, almost there. It seems that the OPTIONS method should be allowed too:
DELETE or PUT (or other non-simple) requests first send out a preflighted OPTIONS request to determine if you're allowed to send this request. The request method is given in the Access-Control-Request-Method header.@axllent commented on GitHub (May 9, 2023):
The never-ending story :) I did some digging as to what that response should respond with ~ and found mixed results. I've set the response to all
api/v1/*OPTIONS requests to return a blank 200 response (which contains the right headers), so I'm really hoping this does the trick! I think the OPTIONS request includes the method it wants to use, which I should possibly be checking against the allowed methods, however I'm just trying to get it working. This has been released now with v1.6.9.@alainmaradan commented on GitHub (May 9, 2023):
Hi !
With the latest update, everything works fine now.
Thank you for your time and dedication !
@axllent commented on GitHub (May 10, 2023):
That took a while, but glad to help! You're welcome.