Trusted in this case means, it was Icinga Web that
rendered a link and the user followed it. Whether
a source is trustworthy or not is detected by use
of the user's session id to hash it combined with
the source similar to how CSRF tokens are assembled.
This slipped through, as I thought the CSS selector `:input`, which
was used previously, is invalid. Although, it's a jQuery specific
selector -.-, which was also previously used.
fixes#5293
This is a potential breaking change for behaviors which
rely on being able to change content in-place even if
the response's content is not applied. This is the case
for grafana's iframe behavior, though that's more a hack
than a necessity so it doesn't break. I've found no other
implementations so I guess it's fine including it here.
A redirect caused by a form submit is **never** an automatic submit.
Unless I'm missing something here. There is one way this may be true,
as ipl forms without a submit button are indeed successful due to a
autosubmit element, but they don't redirect by default. So if the
controller redirects in such a case, the form should have a submit
button, I guess..
Anyway, this is necessary due to the previous commit as this may
otherwise cause form submits, that re-render layout during a redirect,
are considered being auto submitted. (Such as the login form)
- Previously, in case of `abort` the url was already pushed to history at the beginning of `onFailure`, setting `addToHistory` to true only prevents it from being added twice (again in `onComplete`).
- Now we only push the url to history in `onComplete`, so setting `addToHistory` to false is only necessary if req is scripted.
- We intentionally push the canceled url into history to continue navigating with the browser`s back/forward key.
`stopPendingRequestsFor()` cancel the pending request but push the canceled url to history (by calling `loader::OnFailure` internally).
Now the `icingaUrl` is set again, remove it and push again the current state to history.
Not the container's base target. The redirect target may still be
overridden by `data-base-target` on the `form` or by the response
using `X-Icinga-Container`.
* Let response header `X-Icinga-Container` either influence a request's `$target` or `$redirectTarget`, but not both
* Close a request's `$target` instead of the `$redirectTarget` upon the redirect url `__CLOSE__`
* Issuing a `__CLOSE__` in a detail url still closes `#col2` and refreshes `#col1`
* Issuing a `__CLOSE__` for a nested container still empties it
* Issuing a `__CLOSE__` in a modal, now refreshes the modal openers container
* If `X-Icinga-Extra-Updates` is set, automatic refreshing won't happen
