Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Protecting against non-permitted state change via API #675

Open
mfdewit opened this issue Mar 10, 2025 · 1 comment
Open

Protecting against non-permitted state change via API #675

mfdewit opened this issue Mar 10, 2025 · 1 comment

Comments

@mfdewit
Copy link

mfdewit commented Mar 10, 2025

Hello,

As discussed some time ago here:
#623

Currently we use Nflow in our production environment and we are quite happy with it. All our interaction with the workflows is taking place using the API so we need a method of protecting against non-permitted state changes. We already had a bug in our frontend software causing problems because a wrong state was forced.

We really want to avoid these situations, and preferably on the Nflow server. Is this something we can add ourselves? I'm willing to create a PR if we agree on a technical solution.

Picking up on our discussion, I am all for configuring this on request level. The most ideal solution would be to distinguish between admin en user requests, but I think that is a bridge too far since Spring security is applied 'at the gate' and currently no role checks are being performed anywhere (from what I can see now). That leaves us with the option to provide a query param to the request, which sounds fine with me.

In the discussion it is mentioned that a check could be performed inside WorkflowInstanceService.wakeupWorkflowInstance(), but shouldn't this check be performed in the WorkflowInstanceService.updateWorkflowInstance() method? This way the client can be directly notified with a bad request.

Regards
Mauro

@RealZimboGuy
Copy link
Contributor

side thought for an interim solution

do a pre-call to workflow-definitions and just parse/validate your own next state, sample response ie

[
    {
        "type": "My-Workflow",
        "onError": "error",
        "states": [
            {
                "id": "userTagSelect",
                "type": "normal",
                "description": "user Selects Tag",
                "transitions": [
                    "promptTagSelect",
                    "error"
                ]
            },
            {
                "id": "promptTagSelect",
                "type": "normal",
                "description": "prompt tags",
                "transitions": [
                    "error",
                    "done"
                ]
            },
            {
                "id": "done",
                "type": "end",
                "description": "done"
            }
        ],
        "settings": {
            "transitionDelaysInMilliseconds": {
                "waitShort": 30000,
                "minErrorWait": 60000,
                "maxErrorWait": 86400000
            },
            "maxRetries": 17,
            "historyDeletableAfter": "P45D",
            "defaultPriority": 0
        }
    }
]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants