How to dynamically discover endpoint - oauth

I want to implement openid connect in my project. Right now I am hard coding the discovery url like for google - https://accounts.google.com/.well-known/openid-configuration , same for other source and then make this call and getting the endpoints for all the respective sources.
but I want to make it full dynamic. I found something on openid.net
GET /.well-known/webfinger
?resource=acct%3Ajoe%40example.com
&rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: application/jrd+json
{
"subject": "acct:joe#example.com",
"links":
[
{
"rel": "http://openid.net/specs/connect/1.0/issuer",
"href": "https://server.example.com"
}
]
}
How can I do this call. What should I placed in resouces, rel ?? I am beginner in oauth process. Could you plz help me out.

very few of the major IdPs support dynamic registration. They all seem to want you to register on a web page where you can agree to their terms of use.
mojeid.cz is one I know that does. If you find others I would like to know.
I am coding up dynamic client now. It's tough. I do plan on posting it on GitHub at some point.   ..tom

Strictly speaking Dynamic Registration is not necessarily coupled one-on-one with Discovery although typically it would be.
As the OP suggests, one can lookup the Provider's metadata through applying Webfinger Discovery as described in: http://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery
The request and response would look as already presented in the question i.e. : http://openid.net/specs/openid-connect-discovery-1_0.html#URLSyntax The RP can parse the "hreft" value from the response that would present the "issuer" value (i.e. a unique DNS bound identifier for the Provider) and then construct the well-known endpoint where the Provider's configuration metadata can be retrieved from as described here: http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
Assuming that the RP already has a client_id/client_secret established with that Provider in a previous out-of-bound step, this may avoid the RP having to store and/or cache the Provider's metadata.

Related

Run a flow from another flow in Twilio

How can I run a flow from another flow in Twilio Studio Flow?
Help with defining the To and From HTTP parameters:
I am a beginner in programming so I am failing to understand the brief notes given in support docs, namely specifying HTTP additional parameters for "To" and "From".
Additional details from comment:
I am trying to run REST API triggered Flow B from primary Flow A by using an http request widget in Flow A in the format below: (as suggested in a similar problem posted on this portal) Widget: HTTP Request [ACCOUNT_SID:AUTH_TOKEN#studio.twilio.com/v1/Flows/THE_OTHER_STUDIO_FLOW_SID/Executions][2] Content Type: Form URL Encoded KEY:VALUES To:+1234567890 From:+2773123456 I am getting error 401. I tried to swap the To number with the From number without success
There are 2 ways you can trigger one twilio studio flow from another
Method 1:
Use the TwiML Redirect Widget. Place the widget where you need it and specify the target studio flow URL there. Studio URLs have the following format
https://webhooks.twilio.com/v1/Accounts/{AccountSid}/Flows/{FlowSid}
Method 2:
Do the same as above programmatically. You can send twilio a twiML response such as the one below
let twiml = new Twilio.twiml.VoiceResponse();
if (something) {
twiml.redirect({
method: 'POST'
}, 'https://webhooks.twilio.com/v1/Accounts/{AccountSid}/Flows/{FlowSid1}');
} else {
twiml.redirect({
method: 'POST'
}, 'https://webhooks.twilio.com/v1/Accounts/{AccountSid}/Flows/{FlowSid2}');
}
For more info, check out https://www.twilio.com/docs/voice/twiml/redirect
Assuming you are not trying to bridge the call between the two flows, this should be possible. To simplify:
You have a call come in on Flow A ("Incoming Call" trigger on Flow A).
Flow A executes its logic.
That logic triggers Flow B by calling its REST API endpoint so that it makes a new outbound call ("REST API" trigger on Flow B).
This last thing is the hard part. Make sure you are looking at the docs for the REST API Execution resource. To trigger a new flow, you need to make a POST request which supplies the To and From parameters.
If you are a beginner at programming, it might be helpful for you to start with a separate HTTP client like Postman to start to get familiar with the structure of an HTTP request, and learn the full extent of what is required to successfully make this API request before you start trying to cram it into Studio and automate it.
That said, this request should be possible to do within the Studio Make HTTP Request widget. If you make your content type Application/JSON, you can pass the To/From parameters directly in a JSON-formatted request body, like this:
{
"To": "+19995551234",
"From": "+12345556789"
}
To be perfectly honest, I don't know what the widget means by "Http Parameters". This could be HTTP Headers, URI parameters, or something else. I think the JSON form is clearer.
I came across the same situation. The solution for authentication is to change the url to include AccountSid and AuthToken
https://[AccountSid]:[AuthToken]#studio.twilio.com/v2/Flows/[SID]/Executions
Instead of Application / Json, use Form Parameters. Then add individual parameters below, for To, From, and Parameters​ (JSON string) for other variables.

What is the prebid member id?

For prebid-server the example shows json='{"pageOpts": {"member": 958,"invCode": "ast_guaranteed_prios_1","..., especially the member value. Without setting this, requests to https://ib.adnxs.com/ut/v3
fail with
{"error":"Could not find valid member in request"}
What is pageOpts.member? Which value should it be set to?
The example you gave is not for prebid-server, it is for accessing Appnexus directly. In order to setup prebid server you should follow their AMP instructions here. Also, to debug the auction on the client side you can add: &debug=1 to the url that sends the request to prebid-server, it generally is prebid.adnxs.com/pbs/v1/openrtb2/amp?, however that will be different if you use your own hosting.

F5 iRule for UIE - Extracting a value from HTTP response payload/body

We are trying to write a iRule for the BIG-IP universal persistence module.
Our mission is to extract and persist from a HTTP response payload/body an application unique identifier (something like a seesionid for us).
Then use it in a consecutive HTTP requests.
Note, this unique identifier return in text/xml/soap-xml response formats and there is no cookie involve here.
We're having problem to write the TCL code for the extraction of our custom unique identifier from the HTTP response payload/body.
We have checked these manuals and did not find example for this kind of functionality:
https://devcentral.f5.com/wiki/iRules.HTTP_RESPONSE.ashx
https://devcentral.f5.com/wiki/iRules.HTTP__payload.ashx
Thanks.
Here's an example with jsession IDs that should get you started with basic persistence flow, and this example gives you an idea on how to work with payload data.

How to set cache-control header in odata4j?

I'm writing a RESTful service using odata4j and need to be able to set the caching header of the response.
How do I do this?
I don't seem to have access to the HttpservletResponse object.
And unlike the JAX-RS support, I can't see anything in odata4j that lets me get hold of a CacheControl object.
Thanks
Sarah
No direct support for this as of 0.5 - however you could write a custom ContainerResponseFilter to modify the outgoing response manually.
Feel free to add a feature request on the project issue list [1], along with any detail on a proposed api if you have thoughts on how this might work.
Or, of course, a patch... : )
Hope that helps,
- john
[1] http://code.google.com/p/odata4j/issues/list

Is this RESTful?

I have a Rails app that needs to expose values from a database as a web service - since I'm using Rails 2.x, I'm going with REST (or at least try). Assuming my resource is Bananas, for which I want to expose several sub-characteristics, consider this:
- /banana -> give a summary of the first 10 bananas, in full (all characteristics)
- /banana/?name=<name> -> give all characteristics for banana named <name>
- /banana/?number=<number> -> give all characteristics for banana number <number>
- /banana/?name=<name>/peel -> give peel data for banana named <name>
- /banana/?number=<number>/length -> give length data for banana number <number>
I don't want to search for ID, only name or number. And I have about 7 sub-characteristics to expose. Is this RESTful?
Thanks for any feedback!
What Wahnfrieden is talking about is something called Hypermedia as the Engine of Application State (HATEOAS) - a central constraint of REST as defined by Fielding.
In a nutshell, REST application clients never construct URIs themselves. Instead, they follow URIs provided by the application. So, URI templates such as the ones you're asking about are irrelevent at best. You can make them conform to a system if you'd like, but REST says nothing about how your URIs need to look. You could, if you wanted to, arrange it so that every resource in your system was available from http://example.com/{hash}.
Publishing URI templates, such as the ones you're talking about in your question, introduces tight coupling between your application and clients - something REST is trying to prevent.
The problem with understanding hypermedia-driven applications is that almost nobody implements or documents their "RESTful" systems this way.
It might help to think about the interaction between a human and server via a browser. The human only knows about content and links that the server provides through the browser. This is how a RESTful system should be built. If your resources aren't exposing links, they're probably not RESTful.
The advantage is that if you want to change your URI system, for example, to expose the Banana "Peel" attribute through a query parameter instead of a nested URL, you can do it anytime you'd like and no client code needs to be changed because they're not constructing links for themselves.
For an example of a system that embraces the hypertext-driven constraint in REST, check out the Sun Cloud API.
I would use these:
/banana
/banana/blah
/banana/123
/banana/blah/peel (and /banana/123/peel)
/banana/blah/length (and /banana/123/length)
First, common practice for ReSTful URIs is /object_name/id/verb, with some of those absent (but in that order). Of course, this is neither required nor expected.
If all your names aren't made of digits, you don't have to explicitly have name in /banana/name/blah. In fact, if anything, it would be better to have id as identifier: /banana/id/123/peel. Hope this helps.
Parameters should only be used for form submission.
Also, URI naming schemas is totally unrelated to REST. The point of REST is to make related resources discoverable via hypertext, not out-of-band conventions, and only from a limit number of entry points. So your /bananas/ entry point might provide the summary info for 10 bananas, but it must also provide the URI for each of those bananas' details resources, as well as the URI to get the summary for the next 10 bananas. Anything else is just RPC.
It is good practice in REST to not use query parameters because query parameters don´t belong to a URL and in REST all resources should be addressable through a URL.
In your example /banana/?name=name should be /banana/name because you are referring a concrete resource.
Even I think /banana/?number=number/length is not good REST style, because you are selecting an attribute through a URL when you should retrieve the whole state with /banana/name . A difference could be /customers/1024/address to get the Customer 1024 address record.
HTH.
A more opt form for the route in url having query string is the plural form, as it is possible that multiple items are returned in the result. In this case, bananas, like bananas?color=yellow, sounds more appropriate.
On the other hand, the singular form banana, like banana/123, is good when fetching a specific resource's representation when its identifier is known and query string is not required.

Resources