Some IDPs (e.g. Microsoft) create tokens whose `iss` claim can vary from user
to user. Under the current version, UAA was unable to integrate with these
providers because it requires a single, specific issuer value to be present.

To enable UAA to integrate with providers who do this, we implement different
modes for validating the `iss` claim, under the `issuerValidationMode`
configuration property for OIDC providers

The modes are

STRICT
  The default behaviour. The string in the `iss` claim and the configured
  issuer URL must match exactly.

DOMAIN_ONLY
  The value of the `iss` claim and the configured issuer URL must be URLs. They
  are considered to match if their domains match. Subdomains are not considered
  to match a parent domain.

At the moment, when the user visits:

```
/invitations/accept?code=some-code
```

the invitation code from their email is immediately expired and replaced
with a newly generated code which is put in a hidden input in the HTML
form. Each time the user submits the form, the code is expired and (if
necessary - e.g. if there's a validation issue) replaced with a new one.

This is fine so long as the user fills the form in immediately, but
there are a number of edge cases where this approach causes usability
problems:

1) If the user refreshes the page it will tell them their invitation has
   expired.
2) If the user closes the tab without submitting the form, and then
   follows the invitation link from their email later it will show as
   expired.
3) If the user's email client or web browser pre-fetches the link for
   any reason (e.g. virus scanning / spam detection / performance
   optimisation) then the link will not work when they follow it for
   real.

The third issue is the most serious.

We (GOV.UK PaaS) have had some very users working in places that
pre-fetch links in emails (for some reason or other), and this means
they're completely unable to accept invitations. Judging from the irate
support tickets we've had from these users the experience is pretty
frustrating.

This commit changes the GET request to /invitations/accept so that it
does not expire the token (unless the invitation is being auto-accepted).

The POST handler is unchanged, so if the user actually submits the form
then the token will change (as it did before), even if there's a
validation issue that prevents the invitation being accepted.

This change fixes the usability issues, and makes the behaviour more
consistent with HTTP's semantics (in the sense that GET requests should
be "safe" - should not modify the state of the server).

Some IDPs (e.g. Microsoft) create tokens whose `iss` claim can vary from user
to user. Under the current version, UAA was unable to integrate with these
providers because it requires a single, specific issuer value to be present.

To enable UAA to integrate with providers who do this, we implement different
modes for validating the `iss` claim, under the `issuerValidationMode`
configuration property for OIDC providers

The modes are

STRICT
  The default behaviour. The string in the `iss` claim and the configured
  issuer URL must match exactly.

DOMAIN_ONLY
  The value of the `iss` claim and the configured issuer URL must be URLs. They
  are considered to match if their domains match. Subdomains are not considered
  to match a parent domain.

At the moment, when the user visits:

```
/invitations/accept?code=some-code
```

the invitation code from their email is immediately expired and replaced
with a newly generated code which is put in a hidden input in the HTML
form. Each time the user submits the form, the code is expired and (if
necessary - e.g. if there's a validation issue) replaced with a new one.

This is fine so long as the user fills the form in immediately, but
there are a number of edge cases where this approach causes usability
problems:

1) If the user refreshes the page it will tell them their invitation has
   expired.
2) If the user closes the tab without submitting the form, and then
   follows the invitation link from their email later it will show as
   expired.
3) If the user's email client or web browser pre-fetches the link for
   any reason (e.g. virus scanning / spam detection / performance
   optimisation) then the link will not work when they follow it for
   real.

The third issue is the most serious.

We (GOV.UK PaaS) have had some very users working in places that
pre-fetch links in emails (for some reason or other), and this means
they're completely unable to accept invitations. Judging from the irate
support tickets we've had from these users the experience is pretty
frustrating.

This commit changes the GET request to /invitations/accept so that it
does not expire the token (unless the invitation is being auto-accepted).

The POST handler is unchanged, so if the user actually submits the form
then the token will change (as it did before), even if there's a
validation issue that prevents the invitation being accepted.

This change fixes the usability issues, and makes the behaviour more
consistent with HTTP's semantics (in the sense that GET requests should
be "safe" - should not modify the state of the server).

[#171053583] Bump UAA to v74.13.0

Some IDPs (e.g. Microsoft) create tokens whose `iss` claim can vary from user
to user. Under the current version, UAA was unable to integrate with these
providers because it requires a single, specific issuer value to be present.

To enable UAA to integrate with providers who do this, we implement different
modes for validating the `iss` claim, under the `issuerValidationMode`
configuration property for OIDC providers

The modes are

STRICT
  The default behaviour. The string in the `iss` claim and the configured
  issuer URL must match exactly.

DOMAIN_ONLY
  The value of the `iss` claim and the configured issuer URL must be URLs. They
  are considered to match if their domains match. Subdomains are not considered
  to match a parent domain.

At the moment, when the user visits:

```
/invitations/accept?code=some-code
```

the invitation code from their email is immediately expired and replaced
with a newly generated code which is put in a hidden input in the HTML
form. Each time the user submits the form, the code is expired and (if
necessary - e.g. if there's a validation issue) replaced with a new one.

This is fine so long as the user fills the form in immediately, but
there are a number of edge cases where this approach causes usability
problems:

1) If the user refreshes the page it will tell them their invitation has
   expired.
2) If the user closes the tab without submitting the form, and then
   follows the invitation link from their email later it will show as
   expired.
3) If the user's email client or web browser pre-fetches the link for
   any reason (e.g. virus scanning / spam detection / performance
   optimisation) then the link will not work when they follow it for
   real.

The third issue is the most serious.

We (GOV.UK PaaS) have had some very users working in places that
pre-fetch links in emails (for some reason or other), and this means
they're completely unable to accept invitations. Judging from the irate
support tickets we've had from these users the experience is pretty
frustrating.

This commit changes the GET request to /invitations/accept so that it
does not expire the token (unless the invitation is being auto-accepted).

The POST handler is unchanged, so if the user actually submits the form
then the token will change (as it did before), even if there's a
validation issue that prevents the invitation being accepted.

This change fixes the usability issues, and makes the behaviour more
consistent with HTTP's semantics (in the sense that GET requests should
be "safe" - should not modify the state of the server).

Some IDPs (e.g. Microsoft) create tokens whose `iss` claim can vary from user
to user. Under the current version, UAA was unable to integrate with these
providers because it requires a single, specific issuer value to be present.

To enable UAA to integrate with providers who do this, we implement different
modes for validating the `iss` claim, under the `issuerValidationMode`
configuration property for OIDC providers

The modes are

STRICT
  The default behaviour. The string in the `iss` claim and the configured
  issuer URL must match exactly.

DOMAIN_ONLY
  The value of the `iss` claim and the configured issuer URL must be URLs. They
  are considered to match if their domains match. Subdomains are not considered
  to match a parent domain.

At the moment, when the user visits:

```
/invitations/accept?code=some-code
```

the invitation code from their email is immediately expired and replaced
with a newly generated code which is put in a hidden input in the HTML
form. Each time the user submits the form, the code is expired and (if
necessary - e.g. if there's a validation issue) replaced with a new one.

This is fine so long as the user fills the form in immediately, but
there are a number of edge cases where this approach causes usability
problems:

1) If the user refreshes the page it will tell them their invitation has
   expired.
2) If the user closes the tab without submitting the form, and then
   follows the invitation link from their email later it will show as
   expired.
3) If the user's email client or web browser pre-fetches the link for
   any reason (e.g. virus scanning / spam detection / performance
   optimisation) then the link will not work when they follow it for
   real.

The third issue is the most serious.

We (GOV.UK PaaS) have had some very users working in places that
pre-fetch links in emails (for some reason or other), and this means
they're completely unable to accept invitations. Judging from the irate
support tickets we've had from these users the experience is pretty
frustrating.

This commit changes the GET request to /invitations/accept so that it
does not expire the token (unless the invitation is being auto-accepted).

The POST handler is unchanged, so if the user actually submits the form
then the token will change (as it did before), even if there's a
validation issue that prevents the invitation being accepted.

This change fixes the usability issues, and makes the behaviour more
consistent with HTTP's semantics (in the sense that GET requests should
be "safe" - should not modify the state of the server).

Bump UAA to 74.16.0

Some IDPs (e.g. Microsoft) create tokens whose `iss` claim can vary from user
to user. Under the current version, UAA was unable to integrate with these
providers because it requires a single, specific issuer value to be present.

To enable UAA to integrate with providers who do this, we implement different
modes for validating the `iss` claim, under the `issuerValidationMode`
configuration property for OIDC providers

The modes are

STRICT
  The default behaviour. The string in the `iss` claim and the configured
  issuer URL must match exactly.

DOMAIN_ONLY
  The value of the `iss` claim and the configured issuer URL must be URLs. They
  are considered to match if their domains match. Subdomains are not considered
  to match a parent domain.

At the moment, when the user visits:

```
/invitations/accept?code=some-code
```

the invitation code from their email is immediately expired and replaced
with a newly generated code which is put in a hidden input in the HTML
form. Each time the user submits the form, the code is expired and (if
necessary - e.g. if there's a validation issue) replaced with a new one.

This is fine so long as the user fills the form in immediately, but
there are a number of edge cases where this approach causes usability
problems:

1) If the user refreshes the page it will tell them their invitation has
   expired.
2) If the user closes the tab without submitting the form, and then
   follows the invitation link from their email later it will show as
   expired.
3) If the user's email client or web browser pre-fetches the link for
   any reason (e.g. virus scanning / spam detection / performance
   optimisation) then the link will not work when they follow it for
   real.

The third issue is the most serious.

We (GOV.UK PaaS) have had some very users working in places that
pre-fetch links in emails (for some reason or other), and this means
they're completely unable to accept invitations. Judging from the irate
support tickets we've had from these users the experience is pretty
frustrating.

This commit changes the GET request to /invitations/accept so that it
does not expire the token (unless the invitation is being auto-accepted).

The POST handler is unchanged, so if the user actually submits the form
then the token will change (as it did before), even if there's a
validation issue that prevents the invitation being accepted.

This change fixes the usability issues, and makes the behaviour more
consistent with HTTP's semantics (in the sense that GET requests should
be "safe" - should not modify the state of the server).

[#172697662] Bump UAA to 74.18.0

At the moment, when the user visits:

```
/invitations/accept?code=some-code
```

the invitation code from their email is immediately expired and replaced
with a newly generated code which is put in a hidden input in the HTML
form. Each time the user submits the form, the code is expired and (if
necessary - e.g. if there's a validation issue) replaced with a new one.

This is fine so long as the user fills the form in immediately, but
there are a number of edge cases where this approach causes usability
problems:

1) If the user refreshes the page it will tell them their invitation has
   expired.
2) If the user closes the tab without submitting the form, and then
   follows the invitation link from their email later it will show as
   expired.
3) If the user's email client or web browser pre-fetches the link for
   any reason (e.g. virus scanning / spam detection / performance
   optimisation) then the link will not work when they follow it for
   real.

The third issue is the most serious.

We (GOV.UK PaaS) have had some very users working in places that
pre-fetch links in emails (for some reason or other), and this means
they're completely unable to accept invitations. Judging from the irate
support tickets we've had from these users the experience is pretty
frustrating.

This commit changes the GET request to /invitations/accept so that it
does not expire the token (unless the invitation is being auto-accepted).

The POST handler is unchanged, so if the user actually submits the form
then the token will change (as it did before), even if there's a
validation issue that prevents the invitation being accepted.

This change fixes the usability issues, and makes the behaviour more
consistent with HTTP's semantics (in the sense that GET requests should
be "safe" - should not modify the state of the server).

At the moment, when the user visits:

```
/invitations/accept?code=some-code
```

the invitation code from their email is immediately expired and replaced
with a newly generated code which is put in a hidden input in the HTML
form. Each time the user submits the form, the code is expired and (if
necessary - e.g. if there's a validation issue) replaced with a new one.

This is fine so long as the user fills the form in immediately, but
there are a number of edge cases where this approach causes usability
problems:

1) If the user refreshes the page it will tell them their invitation has
   expired.
2) If the user closes the tab without submitting the form, and then
   follows the invitation link from their email later it will show as
   expired.
3) If the user's email client or web browser pre-fetches the link for
   any reason (e.g. virus scanning / spam detection / performance
   optimisation) then the link will not work when they follow it for
   real.

The third issue is the most serious.

We (GOV.UK PaaS) have had some very users working in places that
pre-fetch links in emails (for some reason or other), and this means
they're completely unable to accept invitations. Judging from the irate
support tickets we've had from these users the experience is pretty
frustrating.

This commit changes the GET request to /invitations/accept so that it
does not expire the token (unless the invitation is being auto-accepted).

The POST handler is unchanged, so if the user actually submits the form
then the token will change (as it did before), even if there's a
validation issue that prevents the invitation being accepted.

This change fixes the usability issues, and makes the behaviour more
consistent with HTTP's semantics (in the sense that GET requests should
be "safe" - should not modify the state of the server).

Bumps [github.com/onsi/ginkgo](https://github.com/onsi/ginkgo) from 1.14.2 to 1.15.0.
- [Release notes](https://github.com/onsi/ginkgo/releases)
- [Changelog](https://github.com/onsi/ginkgo/blob/master/CHANGELOG.md)
- [Commits](onsi/ginkgo@v1.14.2...v1.15.0)

Signed-off-by: dependabot[bot] <support@github.com>