API for integrations and automatization

[Kenya-West]

Is your feature request related to a problem? Please describe.
As a developer, I want to extend X-UI capabilities and automate its deployment and configuration. I want a separate API to manage all its configuration and adding/editing/removing users/inbounds/outbounds, and so on.

Describe the solution you'd like
I want X-UI to have a separate entrypoint; the default one could be /api, but with security in mind: it could be PAT, or cookie, or special custom query string with special processing on backend, whatever. Any possible miss and X-UI' server responds as if /api did not ever exist.

Describe alternatives you've considered
I tried to run NGINX and Caddy proxy next to X-UI to avoid CORS and access X-UI's internal API, but with no luck: X-UI asks for cookie file and then responds with HTTP 301 Redirect. I managed to bypass this protection but it is overly complicated, with no documentation at all.

Why is it needed
When you deploy new X-UI instance to a server, it is hard to configure it automatically. Of course, you can automatically generate and configure bare XRay... but X-UI offers much more capabilities with more convenient way, and subscriptions is the top feature.

[fuad00]

To use it, you can use the documentation in the API section in the link below:

https://github.com/alireza0/x-ui

[mhsenpc]

The panel is using rest api to interact to the backend so you can easily simulate the requests and send them to the backend. all you need is just a valid cookie that can be gathered by send a post request to /login
by that valid cookie, you can send different requests to add an outbound, add a user, edit a user, get the config settings and so on.

I have implemented a telegram bot which talks to XUI in order to create users and retrieve information from the outbounds. you might find it useful

https://github.com/mhsenpc/xui-telegram-bot

the implemented code to interact to XUI is in this directory

[Kenya-West]

Important addition to my issue @mhsenpc @fuad00: this is related to frontend clients building.

Sorry for not narrowing the scope of the problem before.

I am building a web app as frontend client for X-UI's Go server.

The problem is: there is authentication flow that gives you cookie tied to specific domain after /login POST request. It is OK and is standard way to authenticate. While it is good option for Postman or other REST clients (as they easily remember the cookie and you do not need to care about this), it could be a problem for frontends that live on other domains.

Not even mentioning CORS restriction but it can be bypassed with NGINX reverse proxy running next to X-UI's instance.

We have:

• X-UI on sub1.domain.tld;
• Some frontend client on sub2.domain.tld.

Frontend client tries to login. It logins successfully but the cookie it gets relies to sub1.domain.tld and frontend on sub2.domain.tld cannot set it since browser does not allow to see cookies from other domains (see policy).

Conclusion: Postman works good, 3rd party frontend clients cannot work because cookie is inaccessible.