Closed 0x4E4448 closed 3 months ago
What is the url that you access the login page with? The login page uses the same path that it was accessed with.
What is the url that you access the login page with? The login page uses the same path that it was accessed with.
At the time I was attempting to deploy this, I was attempting to make it a subpath of the domain. E.g. domain.com/calendar/. That worked, however, if I attempted to go to domain.com/calendar/admin/ it would submit the admin login form to domain.com/admin/, which was not the correct page. The only way to get around this was to add a redirect for domain.com/admin/ to domain.com/calendar/admin/, which isn't sufficient in situations where you may want to host multiple instances on the same domain.
Other similar form submissions or links appear to correctly use the $base_uri/admin/ path. This instance is hard coded to be at the root of the domain.
This instance is hard coded to be at the root of the domain.
It is not hard coded to the root of the domain. See
https://github.com/sabre-io/Baikal/blob/master/Core/Frameworks/BaikalAdmin/Controller/Login.php#L37
I am running Baikal in a subfolder without any problems. My guess would be that there is something unusual in your server configuration, maybe in an .htaccess
file. Could you check your server configuration for anything unusual please?
Wrong word- it uses an absolute path and not a relative path. That’s clear from the screenshot I included. It forces itself to the root of the domain and does not use $base_uri like other paths do.
I was, when I tried this nearly two years ago, deploying this in Kubernetes using a simple configuration and the container version of Baikal. It was one of the first couple of pods I was trying to deploy in the cluster. Nothing unusual about it.
based on looking at the code you referenced, it’s ignoring the $base_uri and just looking at the request URI. If you’re hosting it behind a reverse proxy, the URI the container sees will be different than what the actual request is. If it used $base_uri then it would prepend it to the URI so when the form is requested it submits to the proper path and can be proxies to the correct container.
running into a most likely connected issue here, running behind a reverse proxy.
i was able to access baikal just fine on my internal network with it's ip. but accessing it via reverse proxy kept switching me back to ip, because all the links in the UI pointed to the ip.
now i went to the config dir (/var/www/config in my case, with the content being in the usual /var/www/html) and changed the base_uri to the uri i use from outside, via reverse proxy.
Now the links (at least the login link) for some reason point to https://
this is on baikal 0.9.4 installed via the install instructions (download zip + unzip to the proper place)
Baikal version: 0.9.2
Expected behaviour: Enter credentials in $base_uri/admin/ and click Authenticate. POST should submit to $base_uri/admin/.
Current behaviour: POST submits to /admin/ without $base_uri prefix.
Steps to reproduce: