The ability for oneshot to print/return information about the GET request (for oidc flows)

[andrewpatto]

When doing development / debug / testing of oauth/openid flows - the interactive web browser portion finishes with a redirect to a URL that is meant to receive the authorisation code in a URL param (at which point it will go and do some code exchanges).

Scripting testing of this in something like bash is painful - but I think oneshot with very minimal additions could help out.

As a proof of concept - I used oneshot like this

 oneshot -D -S 'echo "$QUERY_STRING"'

and set up my oauth redirect to http://127.0.0.1:8080.

I initiated my oauth flow in bash, launched a browser to do the login portion, and see that the page then redirects to oneshot with a GET of

http://127.0.0.1:8080?code=ABCDEFGH&state=XYZ

(i.e. the browser shows the output of the shell/CGI and then exits .. code=ABCDEFGH&state=XYZ)

However, I have no way of getting that information out of the invocation of oneshot in my bash script. I was thinking of a series of command line flags that would instruct oneshot to print this information on the end of the request.

So something like

--echo-from-client query_string

where the sky is the limit for what details of the client could be shown. I'd possibly start with any of the variables that are in the environment of the CGI launch.

query_string
http_user_agent
remote_host
http_accept

So the expected invocation pattern would be

QUERY=$(oneshot -q -D -S 'echo "Thanks"' --echo-from-client query_string)

I realise this is a bit outside the box from what oneshot was intended for - but does fall into the category of things that I need a http server that only responds once for!

[raphaelreyna]

I realise this is a bit outside the box from what oneshot was intended for ...

Not at all. I think of oneshot as not just a file transfer utility but also as a tool for developers to use in their workflows; makes sense to me to include this.

I like the idea of exposing several parts of the incoming request; the entire query string, the url params, headers, etc...
Basically this struct: https://pkg.go.dev/net/http#Request

However, I'm not sure how the output should be formatted; I'm thinking adding a --json-output flag and possibly even a --template-output flag (for user defined templated output using tfortools) might be a good solution. So by default the user would get the same human-readable output that oneshot currently spits out, but if the user wants to use oneshot in pipeline/workflow they could then opt for machine-readable output. Your thoughts on this would be appreciated if you would care to share them 🙂

[andrewpatto]

I think getting the info out at all was my first thought - and I hadn't really thought about the formatting.

Agree with you that there are probably two use cases - one for users by default that just displays something friendly.. and a machine readable output for pipeline/workflows. I think that sounds sensible to me.

[andrewpatto]

If there is a flag that gets the entire incoming request structure to output as JSON - it is certainly trivial to process that with jq (etc) so that is a good solution for me

[raphaelreyna]

Sorry for such a long delay in my response, but I've finally been able to dedicate some time to this project and have recently released a beta for v2 which I think more than solves this issue by providing rich JSON reports including stats and the requests of both unsuccessful and successful transfers.