Not working dagu after update to v1.12.1

[jheredianet]

Hi, after updating a few hours ago, it the following errors when opening the dagu Web to browse the dugs (http://myweb:8080/dags)

http://0.0.0.0:8080/api/v1//dags

I've seen in the developer windows to know what is happening and found this

I had to revert to version v1.11.0

[cocoonkid]

Same problem here!

[yottahmd]

Oh sorry, let me check!

[yottahmd]

@jheredianet @cocoonkid The bug is now fixed in version 1.12.2 Could you please if it is working on your end? If you encounter any issues, try clearing your browser cache.
@jheredianet Thanks a lot for submitting the issue and apologies for the delayed response!

[jheredianet]

Hi, I've tried and seems to be working using http:// (the path seems to be solved).

But since I have it behind a proxy https:// it does not work (scheme error)

It works perfectly on versión v1.11.0 with http:// and https://

[cocoonkid]

I will test soon but also behind a reverse proxy so probably will encounter the same issue as @jheredianet

[clarson99]

I had the same issue with 1.12.1 and 1.12.2 and had to revert to 1.11.0. Im running in docker compose and everything worked fine locally, but I was not able to deploy to dev and use a hostname other than 'localhost'.

It seems the DAGU_HOST env var is used to bind the IP address and the VUE app is trying to use the same value to know where the scheduler host is.

My guess is, you need 2 separate env vars, one for binding and one for the DNS name that VUE uses.

[yottahmd]

Hi, I've tried and seems to be working using http:// (the path seems to be solved).

But since I have it behind a proxy https:// it does not work (scheme error)

It works perfectly on versión v1.11.0 with http:// and https://

it started using go-swagger from 1.12.0, so that's probably the reason. I'll look into finding a workaround for this issue.

[yottahmd]

I had the same issue with 1.12.1 and 1.12.2 and had to revert to 1.11.0. Im running in docker compose and everything worked fine locally, but I was not able to deploy to dev and use a hostname other than 'localhost'.

It seems the DAGU_HOST env var is used to bind the IP address and the VUE app is trying to use the same value to know where the scheduler host is.

My guess is, you need 2 separate env vars, one for binding and one for the DNS name that VUE uses.

Thanks for sharing your experience! Could you help me understand why having the same DAGU_HOST value is causing issues in your environment?

[clarson99]

I had the same issue with 1.12.1 and 1.12.2 and had to revert to 1.11.0. Im running in docker compose and everything worked fine locally, but I was not able to deploy to dev and use a hostname other than 'localhost'.
It seems the DAGU_HOST env var is used to bind the IP address and the VUE app is trying to use the same value to know where the scheduler host is.
My guess is, you need 2 separate env vars, one for binding and one for the DNS name that VUE uses.

Thanks for sharing your experience! Could you help me understand why having the same DAGU_HOST value is causing issues in your environment?

@yohamta When DAGU_HOST=somename.com then the container wont even start, it gives a stacktrace when it tries to bind to the IP address somename.com.

Then, when you unset DAGU_HOST, the container will start and bind to 0.0.0.0:8080, but then when you access the site in the browser, the page only partially renders. If you check the console log in the dev tools, you can see Vue is trying to find the backend at http://0.0.0.0:8080, but it should be trying to hit http://somename.com:8080.

In other words, both setting and not setting DAGU_HOST results in an error when running somewhere other than localhost.

[yottahmd]

@clarson99 Oh I see, thanks! I will fix this issue this week.

[cocoonkid]

I tested and yes. Behind my nginx reverse proxy still appearing:

I also noticed the button "New" becomes only usable after a refresh or two most of the time.

[yottahmd]

@jheredianet @cocoonkid @clarson99
Hi, updating to version 1.12.3 should resolve the issue. Please give it a try and let me know if it works. Sorry for any inconvenience.

[yottahmd]

Regarding the unusable NEW button issue, I was not aware of it. Please let me know if there's any condition to replicate that.

[jheredianet]

@yohamta Thank you, it's working now, but there is another issue with Basic Auth. It's not working as expected. I had to comment it in the "admin.yaml" file to get it working.
I think it is something about this 1388c18

[cocoonkid]

Wow you are fast :) It works yes.

The button issue seems gone.

It appeared when I had only one dag example called test.

[yottahmd]

@jheredianet Just wanted to check in—are you using these environment variables?

DAGU_IS_BASICAUTH=1
DAGU_BASICAUTH_USERNAME=XXX
DAGU_BASICAUTH_PASSWORD=YYY

Thanks!

[jheredianet]

I've tried both ways as described here 1388c18

Using environment variables or admin.yaml file.

[yottahmd]

@jheredianet Updating to v1.12.4 should resolve the basic auth issue. Apologies for any inconvenience caused!

[jheredianet]

Sorry, it does not work. Now I can get to the webpage with any credentials.
I've teste with the "admin.yaml" file and environment variables.

I've testing even with "Icongnite mode (inPrivate window)" and can get directly to the web without the login dialog.

[yottahmd]

@jheredianet Hmm I could not replicate that on my environment. Could you please check if it happens with the configuration below?

location: ~/.dagu/admin.yaml

isBasicAuth: 1
basicAuthUsername: XXX
basicAuthPassword: YYY

[jheredianet]

Hi, never mind. I was testing with Microsoft Edge (inPrivate Window), but tried with Opera and yes, it asks for login credentials. I must be something about the browser.

Thank you very much for fixing the issue.