I'm using OpenApiGenerator v5.0 beta csharp-netcore. The configuration has ApiKeyPrefix and ApiKey, both of which are Dictionary<string, string>. It seems that the token used is
ApiKeyPrefix["Authorization"] + " " + ApiKey["Authorization"]
Is there a way to choose which token to use? I see Configuration.GetApiKeyWithPrefix takes a string which enables me to choose which key to inspect, but I don't see a way to choose which key to use in an individual request.
I got so carried away looking at the source code and intellisense I forgot that I can just look in the generated code in my own project. I can see that the choice to use the prefix and token identified by the "authorization" key is indeed hard coded. I'll have to either edit the generated code or request a change on the OpenApi Generator repo.
Related
I want to do something very similar to what's shown in the docs for FSharp.Data:
The URL I'm requesting from though (TFS) requires client authentication. Is there any way I can provide this by propagating my Windows creds? I notice JsonProvider has a few other compile-time parameters, but none seem to be in support of this.
You don't have to provide a live URL as a type parameter to JsonProvider; you can also provide the filename of a sample file that reflects the structure you expect to see. With that feature, you can do the following steps:
First, log in to the service and save a JSON file that reflects the API you're going to use.
Next, do something like the following:
type TfsData = JsonProvider<"/path/to/sample/file.json">
let url = "https://example.com/login/etc"
// Use standard .Net API to log in with your Windows credentials
// Save the results in a variable `jsonResults`
let parsedResults = TfsData.Parse(jsonResults)
printfn "%A" parsedResults.Foo // At this point, Intellisense should work
This is all very generic, of course, since I don't know precisely what you need to do to log in to your service; presumably you already know how to do that. The key is to retrieve the JSON yourself, then use the .Parse() method of your provided type to parse it.
I'm trying to connect to the StackExchange API in R.
When I try:
library(httr)
end <- oauth_endpoint(authorize = "https://stackoverflow.com/oauth",
access = "https://stackoverflow.com/oauth")
myapp <- oauth_app("myapp",
key = "KEY", # tried swapping these
secret = "CLIENT SECRET",
redirect_uri = "https://stackoverflow.com/oauth/login_success")
token <- oauth2.0_token(end,
myapp)
The browser opens but leads to the following message (in the browser):
Couldn't parse `client_id`
This also happens if I try it with opposite (reversed) values of key and secret, or event with key set to either value and secret=NULL (just to test without privileged access).
The StackExchange API docs say that the key value they give you is not really a secret but the client_secret value is. In the oauth_app help it says that the secret "is not equivalent to a password, and is not really a secret". Interesting.
For now I'm just trying to establish an initial test connection.
Update:
I was curious if it was actually a matter of not being able to parse special character. I tried escaping the 2 parentheses ((() in my key and client_secret. That didn't change anything. I then tried setting both to an empty string (i.e. key = "", etc) and yet that somehow led to the same result. I feel it's a clue but I still don't know what's wrong.
You're using implicit ("Client side") OAuth(SE API Doc).
That means that the auth sequence should look like this example:
Your app HTTP GETS:
https://stackexchange.com/oauth/dialog?client_id=4709&scope=private_info&redirect_uri=https://stackexchange.com/oauth/login_success
Where client_idand scope are set to your circumstances.
Your app is then redirected to:
https://stackexchange.com/oauth/login_success#access_token=wdR8Lm7m4ibD48lfrCcFxQ))&expires=86399
For example.
Where access_token is what you need for subsequent calls that require authentication.
I'm no r coder, but guess that the syntax should be something like:
myapp <- oauth_app("myapp",
client_id = "{Your App's ID}",
scope = "private_info", # Or whatever is desired. See the doc page linked above
redirect_uri = "https://stackoverflow.com/oauth/login_success")
client_secret is only used for server-side (explicit) OAuth.
pass key in all subsequent calls, OAuth needed or not, for quota purposes.
I was getting the same error, my issue was that I was using the client secret as a value for my client_id parameter
Is there a way to navigate the user to a Relying Party, which has a querystring parameter?
BackGround
We are using ADFS 2.0 wherein we have setup the Relying Party trust with Claim Rules for Single Sign On (SSO) of a vendor application. We are doing this using IdpInitiatedSignOn and SAML 2.0. So, we are able to navigate the user to a SSO like mycompany.com; however we are not able to figure out, how to navigate the user to a different page of same application which has a query string parameter e.g. mycompany.com?index = 123
We tried to use RelayState to resolve this, but no luck. This is my first post. My apologies if I have missed on giving enough information.
It's possible to do a direct SSO with a deep link. There are several walkthroughs, but they aren't terrible clear about what you need. As I used them for this answer, I will share them.
TLDR answer:
**[ADFS base URL]**/adfs/ls/idpinitiatedsignon.aspx?RelayState=EncodedURL(RPID=EncodedURL(**[LoginToRP value]***)&RelayState=EncodedURL(**[Destination URL]**))
Target: mydestinationURL
LoginRPID: myLoginRPIDValue
Base ADFS URL: https://adfs.myDomain.com/adfs/ls/idpinitiatedsignon.aspx
Example: https://adfs.myDomain.com/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3DmyLoginRPIDValue%26RelayState%3DmydestinationURL
References:
website to break down proper SAML and direct one way auth: http://www.confusedamused.com/notebook/adfs-relaystate
website to help generate/validate proper URL: https://jackstromberg.com/adfs-relay-state-generator/
website for HTML encoding values: https://www.url-encode-decode.com/
Logic breakdown:
1A) HTML Encode the target URL
1B) HTML Encode the LoginToRP parameter
2) Concatenate them together in this format: RPID=[HTML Encoded LoginToRP value]&RelayState=[HTML Encoded Target URL]
3) HTML Encode concatenated String
4) Concatenate Base URL and encoded string: [base URL]?RelayState=[double encoded string]
5) Result:
https://adfs.myDomain.com/adfs/ls/idpinitiatedsignon.aspx?RelayState=RPID%3DmyLoginRPIDValue%26RelayState%3DmydestinationURL
I know that in most MVC frameworks, for example, both query string params and form params will be made available to the processing code, and usually merged into one set of params (often with POST taking precedence). However, is it a valid thing to do according to the HTTP specification? Say you were to POST to:
http://1.2.3.4/MyApplication/Books?bookCode=1234
... and submit some update like a change to the book name whose book code is 1234, you'd be wanting the processing code to take both the bookCode query string param into account, and the POSTed form params with the updated book information. Is this valid, and is it a good idea?
Is it valid according HTTP specifications ?
Yes.
Here is the general syntax of URL as defined in those specs
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
There is no additional constraints on the form of the http_URL. In particular, the http method (i.e. POST,GET,PUT,HEAD,...) used don't add any restriction on the http URL format.
When using the GET method : the server can consider that the request body is empty.
When using the POST method : the server must handle the request body.
Is it a good idea ?
It depends what you need to do. I suggest you this link explaining the ideas behind GET and POST.
I can think that in some situation it can be handy to always have some parameters like the user language in the query part of the url.
I know that in most MVC frameworks, for example, both query string params and form params will be made available to the processing code, and usually merged into one set of params (often with POST taking precedence).
Any competent framework should support this.
Is this valid
Yes. The POST method in HTTP does not impose any restrictions on the URI used.
is it a good idea?
Obviously not, if the framework you are going to use is still clue-challenged. Otherwise, it depends on what you want to accomplish. The major use case (redirection of a data subset to a new POST target) has been irretrievably broken by browser implementations (all mechanically following the broken lead of Mosaic/Netscape), so the considerations here are mostly theoretical.
I was wondering if it's acceptable to put custom data in an HTTP authorization header. We're designing a RESTful API and we may need a way to specify a custom method of authorization. As an example, let's call it FIRE-TOKEN authentication.
Would something like this be valid and allowed according to the spec: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
The first part of the second string (before the ':') is the API key, the second part is a hash of query string.
The format defined in RFC2617 is credentials = auth-scheme #auth-param. So, in agreeing with fumanchu, I think the corrected authorization scheme would look like
Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="
Where FIRE-TOKEN is the scheme and the two key-value pairs are the auth parameters. Though I believe the quotes are optional (from Apendix B of p7-auth-19)...
auth-param = token BWS "=" BWS ( token / quoted-string )
I believe this fits the latest standards, is already in use (see below), and provides a key-value format for simple extension (if you need additional parameters).
Some examples of this auth-param syntax can be seen here...
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p7-auth-19#section-4.4
https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin
https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub
Put it in a separate, custom header.
Overloading the standard HTTP headers is probably going to cause more confusion than it's worth, and will violate the principle of least surprise. It might also lead to interoperability problems for your API client programmers who want to use off-the-shelf tool kits that can only deal with the standard form of typical HTTP headers (such as Authorization).
No, that is not a valid production according to the "credentials" definition in RFC 2617. You give a valid auth-scheme, but auth-param values must be of the form token "=" ( token | quoted-string ) (see section 1.2), and your example doesn't use "=" that way.
Old question I know, but for the curious:
Believe it or not, this issue was solved ~2 decades ago with HTTP BASIC, which passes the value as base64 encoded username:password. (See http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side)
You could do the same, so that the example above would become:
Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==