Send request body to authorization server for forward auth

[kyo-ke]

What does this PR do?

The patch is to send request body to authorization server by forwardauth if forwardBody option is true.

Fixes #11029
Also related to community question : https://community.traefik.io/t/forward-auth-middleware-is-there-any-way-to-pass-whole-request-body/20011/2 .

Motivation

Sometimes authorization server want to use request body for authorization. Say some parameter in POST request is only open to specific user.
Always send body is not good for performance so create option for this functionality.

More

• Added/updated tests
• Added/updated documentation

Additional Notes

Request body from client is in body of request to authorization sever.
Do not use header send request body to avoid encoding.

License Information

THIS SOFTWARE IS CONTRIBUTED SUBJECT TO THE TERMS OF THE MIT LICENSE. YOU MAY OBTAIN A COPY OF THE LICENSE AT
https://opensource.org/license/mit

[emilevauge]

Hi @kyo-ke, thanks for your contribution.
However, you added a License Information in your PR description that is not compliant with Traefik's MIT License

License Information
A copyright notice may be inserted here, if appropriate, as discussed in Section
5B below THIS SOFTWARE IS CONTRIBUTED SUBJECT TO THE TERMS OF THE APACHE
LICENSE, V.2.0. YOU MAY OBTAIN A COPY OF THE LICENSE AT
https://www.apache.org/licenses/LICENSE-2.0. THIS SOFTWARE IS LICENSED BY THE
COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OF
NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE. THIS SOFTWARE MAY BE REDISTRIBUTED TO OTHERS ONLY BY
EFFECTIVELY USING THIS OR ANOTHER EQUIVALENT DISCLAIMER IN ADDITION TO ANY
OTHER REQUIRED LICENSE TERMS.

Unless you agree to remove this and use the same license (MIT), we sadly won't be able to merge it.
Thank you for your understanding.

[kyo-ke]

Hi @emilevauge
Thank you for reply.
got it.
Let me check whether this is OK for us.

[kyo-ke]

hi @emilevauge
we agree to MIT License. License information above is changed.
could you review this PR?

[rtribotte]

Hello @kyo-ke,

Thanks for opening this PR!

We have taken a first look at the changes and feel that addressing the configuration of the auth request method should be postponed until the need is raised by the community.
Reusing the incoming request method would probably not fit in every situation, and since the RFC is now more permissive regarding body with the GET method, we think it is still valid to stick with the GET method for now.

[kyo-ke]

Hello @kevinpollet @rtribotte
Thank you for creating PR for review.
merged

[kevinpollet]

Thanks 👍

[rtribotte]

Thanks!