read-only mode, prohibiting editing dags in web ui

[triole]

Hi there,

thanks for Dagu. It's a great tool that I really enjoy using. Please keep up the good work.

Recently I was thinking about a feature that I would very much like to see. Let's call it a "read-only mode" in the web user interface which would be enabled in the server configuration. The idea is, that anyone should be able to have a look at the dags without authentication, but not be able to edit them or create new ones. So basically to use the web interface just for observation purposes.

What do you think? Is it useful? How hard would it be to implement something like this?

Thanks, have a nice day.

[yohamta0]

Hey @triole, thank you for sharing this interesting idea! Just to clarify, are you suggesting that only authenticated users would be able to run or edit DAGs, while others could view them in a read-only mode? I think this could be quite useful, especially when sharing the Web UI with non-tech people. Could you share more details about the authentication method you're using, is it basic authentication or something else?

[ghansham]

I am also interested in this read only mode. May be an option in the base.yaml editDag=false can be used to disable dag editing buttons in UI.

[triole]

Hi,

suggesting the feature I was basically thinking about a way to make sure that people are not able to edit dags in the web interface. Basically because I was concerned about security but still would like to be able to view and maybe run the workflows.

It might be worth thinking about separating running workflows with a second config option to be able to allow or not allow it.

But as a first step allow running would be okay for me. I just want to make sure that no one gets code execution when he or she has access to the web interface. Assuming that existing dags may have run in the past, one would hopefully not be able to gain any critical information on re-running them because former output may already exist in the logs.

So to get back to your auth question... I just had basic authentication in mind. But don't get me wrong. The scenario I favour the most is, having Dagu's web interface running without authentication in read-only mode, if we want to call it like that as a working title for now. So my scenario would allow simple unauthenticated web ui access for information gathering but not allowing to make any changes.

Of course we could think about making differences when authentication is in place and users have access but that would be a little more complicated because it could be expanded to user groups having different levels of access and so on. But it is not something that I would suggest now, because the use case I have in mind is far simpler.

Please let me know what you think.

Thanks and have a nice day.

[triole]

Hi @ghansham ,

There are two points if I read your answer correctly. The first being that Dagu might crash if a user triggers many workflows at once, is more about resilience than security. I get the concern but I did not think of it because it does not belong in the realm of problems that I'd like to address. I was thinking about having limitless code execution which primarily triggers concerns not about resilience. But as I said before, it might make sense to add a second setting to control if user are able to run dags or not.

The workaround having different Linux users is of course something that could be done and in fact there are a few more possibilities than that on system level, but they do not work in every case or are quite awkward to implement. You might for example not be able to choose freely which user runs Dagu because certain file permissions require a certain user. What happens if the root user runs Dagu? There could be dags requiring that. Yes, I know you could do something with chattr but to be honest workarounds like these are quite painful. It would be easier and cleaner to just have a read-only setting for that.

So I would argue not to overcomplicate the issue. Yes, we could discuss post request authentication but this wasn't my intend. It will immediately pose questions like authentication against what? You might need groups and users and different backends and stuff like that. Is it worth the effort? For my use case I'd answer "no". I'd be happy with just a switch to disable or enable the edit and create dags functions.

Cheers.

[triole]

I think the new headless is a step into the right direction. As I see it, it prevents the user's web ui access. I will test a little and use that for now to make sure no one fiddles with dags on any server. Thanks.

[jonnochoo]

Just to chime in, the read only option sounds useful. We currently deploy the DAGs Git, and so don't want people editing code via the web UI.

But being able to do the following is useful

• View logs and jobs
• Run the jobs
• Suspend the jobs

As always appreciate the great work, just sharing a use case.

[yohamta0]

Closing this feature is finally implemented in v1.17.0-beta.1 🎉.

You can now make Dagu UI / API readonly by the config:

permissions:       # Permissions for Web UI and API on the server
  writeDAGs: false  # Allow creating / editing / deleting DAGs
  runDAGs: false    # Allow running / stopping / retrying DAGs

Huge thanks for all the discussion and contributions, @triole, @ghansham, and @jonnochoo !