Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-14738

Avoid 404 response for password-policy in Web apps

    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: L3 - Default L3 - Default
    • None
    • None
    • engine, webapp
    • None

      Acceptance Criteria (Required on creation):

      • The web apps at "<host>/camunda/app/welcome/default" don't receive a 404 response from the REST API if the password policy is disabled

      Hints (optional):

      • Seeing 404 responses in the regular web app execution should point to exceptional cases
      • A disabled password policy is the default configuration of the engine and shouldn't lead to 404 responses in the web apps (and probably also not in general)
      • An empty response for a GET request for password policies might be totally fine
      • If a 404 response is desired when this is disabled to indicate the request does not make sense in this configuration, an endpoint to determine if it is enabled might be a nice addition and should be called by the web apps first before fetching the policy
      • Forum discussion: https://forum.camunda.io/t/password-policy-404-not-found/17209|https://forum.camunda.io/t/password-policy-404-not-found/17209

        This is the controller panel for Smart Panels app

            [CAM-14738] Avoid 404 response for password-policy in Web apps

            Thanks andrius for making us aware!
            We'll have a look as soon as possible and come back with proper feedback.

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - Thanks andrius for making us aware! We'll have a look as soon as possible and come back with proper feedback. Best, Tobias

            Hi andrius,

            I had a closer look at the code that handles the password policy requests:
            https://github.com/camunda/camunda-bpm-platform/blob/4dab4f8be57ac96e4e0c5567d614569dbc027bb7/engine-rest/engine-rest/src/main/java/org/camunda/bpm/engine/rest/impl/IdentityRestServiceImpl.java#L99-L114

            As long as the password policy is disabled (which is the default value), this request will return a 404 NOT FOUND.
            Concerning the code, this behavior is expected and wouldn't qualify as a bug.
            Plus, this behavior was consistently and deliberately used for password policy with CAM-9936.

            Is this behavior preventing you to do anything specific or is this just irritating?

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - Hi andrius , I had a closer look at the code that handles the password policy requests: https://github.com/camunda/camunda-bpm-platform/blob/4dab4f8be57ac96e4e0c5567d614569dbc027bb7/engine-rest/engine-rest/src/main/java/org/camunda/bpm/engine/rest/impl/IdentityRestServiceImpl.java#L99-L114 As long as the password policy is disabled (which is the default value), this request will return a 404 NOT FOUND. Concerning the code, this behavior is expected and wouldn't qualify as a bug. Plus, this behavior was consistently and deliberately used for password policy with CAM-9936 . Is this behavior preventing you to do anything specific or is this just irritating? Best, Tobias

            Thanks for responding so quickly and for the explanation.

            Actually, it's confusing to see REST errors while loading the UI. It always raises the question - is it expected or it's some real error (maybe result of a recent change or upgrade?).

            Andrius Kurtinaitis added a comment - Thanks for responding so quickly and for the explanation. Actually, it's confusing to see REST errors while loading the UI. It always raises the question - is it expected or it's some real error (maybe result of a recent change or upgrade?).

            Andrius Kurtinaitis added a comment - - edited

            I'm not sure if the engine configuration is available to the webapp. If it is - it may make sense to check if the password policy is enabled and only then ask for it.

            That would spare many users one redundant request and this confusing 404.

            Andrius Kurtinaitis added a comment - - edited I'm not sure if the engine configuration is available to the webapp. If it is - it may make sense to check if the password policy is enabled and only then ask for it. That would spare many users one redundant request and this confusing 404.

            Tobias Metzke-Bernstein added a comment - - edited

            Hi andrius,

            I can totally relate to this argumentation, yes

            I will rephrase the ticket to a TASK, proposing to avoid 404 resulting calls to the password policy in the web apps.
            We might either use different calls from the web apps or adjust the answer of the REST API endpoint.
            In the end, you can also argue that delivering an empty result for a GET request for the password policy is sufficient and a 404 is not appropriate here.

            Thanks again for bringing this up.

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - - edited Hi andrius , I can totally relate to this argumentation, yes I will rephrase the ticket to a TASK, proposing to avoid 404 resulting calls to the password policy in the web apps. We might either use different calls from the web apps or adjust the answer of the REST API endpoint. In the end, you can also argue that delivering an empty result for a GET request for the password policy is sufficient and a 404 is not appropriate here. Thanks again for bringing this up. Best, Tobias

            Hi andrius,

            we have discussed the options internally and came to the conclusion that we will not adjust this at the moment.
            The current API behavior is documented in our REST API reference and is therefore expected.
            We see your concern regarding HTTP errors popping up in the web app loading and will consider this for new endpoint calls that we add to the web apps in the future.

            We will leave this ticket in our backlog to track the issue and have solution options at hand. We will however not work on this in the near future.
            That being said, it might become part of future planning nonetheless.

            Best,
            Tobias

            Tobias Metzke-Bernstein added a comment - Hi andrius , we have discussed the options internally and came to the conclusion that we will not adjust this at the moment. The current API behavior is documented in our REST API reference and is therefore expected. We see your concern regarding HTTP errors popping up in the web app loading and will consider this for new endpoint calls that we add to the web apps in the future. We will leave this ticket in our backlog to track the issue and have solution options at hand. We will however not work on this in the near future. That being said, it might become part of future planning nonetheless. Best, Tobias

            This ticket was migrated to github: https://github.com/camunda/camunda-bpm-platform/issues/2763. Please use this link for any future references and continue any discussion there.

            Thorben Lindhauer added a comment - This ticket was migrated to github: https://github.com/camunda/camunda-bpm-platform/issues/2763 . Please use this link for any future references and continue any discussion there.

              Unassigned Unassigned
              andrius Andrius Kurtinaitis
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: