Yes, you’re right. We prevent cross domain requests for security reasons. Please understand that we won’t change that. It’s in your interest and in the interest of all our customers.
Now i think about using a self-hosted solution: zammad-community (ubuntu/inhouse). Not sure my thoughts are right: to manage the cors issue i have to set the “Access-Control-Allow-Origin” in zammad.conf in /etc/nginx/sites-available or im wrong?
Yes that’s correct, please note that you might need to add certificate stuff (ssl) if you want to use https.
You can copy cat from /opt/zammad/contrib/nginx/zammad_ssl.conf if needed.
;
I also tried add_header Access-Control-Allow-Origin *;
and several positions in the file. All leads to a 404 for http://localhost/api/v1/users request.
Is the cause for your problem here.
This is actually not implemented and thus will give you error 404 (not found).
Below you can find all available routes in user context.
api_v1_users_search GET|POST|OPTION /api/v1/users/search(.:format) users#search
api_v1_users_password_reset POST /api/v1/users/password_reset(.:format) users#password_reset_send
api_v1_users_password_reset_verify POST /api/v1/users/password_reset_verify(.:format) users#password_reset_verify
api_v1_users_password_change POST /api/v1/users/password_change(.:format) users#password_change
api_v1_users_preferences PUT /api/v1/users/preferences(.:format) users#preferences
api_v1_users_out_of_office PUT /api/v1/users/out_of_office(.:format) users#out_of_office
api_v1_users_account DELETE /api/v1/users/account(.:format) users#account_remove
api_v1_users_import_example GET /api/v1/users/import_example(.:format) users#import_example
api_v1_users_import POST /api/v1/users/import(.:format) users#import_start
api_v1_users_avatar POST /api/v1/users/avatar(.:format) users#avatar_new
GET /api/v1/users/avatar(.:format) users#avatar_list
DELETE /api/v1/users/avatar(.:format) users#avatar_destroy
api_v1_users_avatar_set POST /api/v1/users/avatar/set(.:format) users#avatar_set_default
api_v1_users_me GET /api/v1/users/me(.:format) users#me
api_v1_users GET /api/v1/users(.:format) users#index
GET /api/v1/users/:id(.:format) users#show
GET /api/v1/users/history/:id(.:format) users#history
POST /api/v1/users(.:format) users#create
api_v1_update_user PUT /api/v1/users/:id(.:format) users#update
api_v1_delete_user DELETE /api/v1/users/:id(.:format) users#destroy
GET /api/v1/users/image/:hash(.:format) users#image
api_v1_users_email_verify POST /api/v1/users/email_verify(.:format) users#email_verify
api_v1_users_email_verify_send POST /api/v1/users/email_verify_send(.:format) users#email_verify_send
api_v1_user_devices GET /api/v1/user_devices(.:format) user_devices#index
DELETE /api/v1/user_devices/:id(.:format) user_devices#destroy
Thank you very much for that information!
Im not sure if im right but
OPTIONS
is part of the pre-flight of an ajax request. this is a part i cant bypass because im sending Authorization in custom header. That’s needed, or im wrong?
Thank you, but even GET returns a 401. That’s weird because the simple CURL call works fine. So my question: Is it possible at all to send a Request by ajax local like this?
Thank you, that’s a good sign I have selected Token-Rights “Admin” , “Users”, “API”. But same issue. Are there other rights required?
Could you also post your CORS-Settings in your nginx config please?