I am trying to implement digest authentication using async-http-client on top of swiftNIO. Therefore I use a class which uses the HTTPClientResponseDelegate protocol. In this class in the
func didReceiveHead(task: HTTPClient.Task<Response>, _ head: HTTPResponseHead) -> EventLoopFuture<Void> {
I parse the first server response and I generate the hash for the response. Now I have to construct the Authorization header with my hash, conforming to the digest authentication. But how can I send it to the server again from my class? Must I make a new HTTPClient.Request or I can make a response with an header directly from my class?
Perhaps somebody can give me a tip how to achieve this using swiftNIO and async-http-client.
Thanks
Arnold
I’m afraid that at the moment you do need to make a new request from your delegate. Currently there is no way to automatically send a new request.
Related
I am using Quarkus with quarkus-smallrye-jwt and I want to access the request headers from a custom subclass of JWTCallerPrincipalFactory as explained by https://quarkus.io/guides/security-jwt#custom-factories. Is there a way to do that?
I solved it by using an implementation of HttpAuthenticationMechanism which has access to the RoutingContext as described here https://quarkus.io/guides/security-customization#httpauthenticationmechanism-customization
I would like to know how to property transfer from one REST API to another REST API?
I worked on the property transfer with the JSON format, but I need to know how to transfer the one REST API response property and use it in the header?
let me explain this using the below scenario:
Admin get the User object by API
Save apiKey from the user object
Call the action on user behalf(By set Authorization Header to Basic with the user apiKey)
To accomplish these steps in soapUI You have to:
Define apiKey in Custom Properties in TestCase
Call resource that returns a User object
Save apiKey property to TestCase.apiKey via property transfer or Groovy Step
Reuse TestCase.apiKey in your nest REST Request step by expanding it via Basic ${=(testCase.getPropertyValue("apiKey")+":").bytes.encodeBase64()}
Hope that helps
I wanted to clarify on a usecase where i struggled to use GET method for a fetch operation.
I was asked to build a API to generate message from a predefined template. In the request i receive template-ID and the dynamic content which needs to be substituted. Dynamic content vary based on the template-ID.
I have designed like
Method = POST
URL pattern = /messagegenerator/v1/templateID
Body = Dynamic Content in the form of JSON
Response = Plain text message
Problem i faced: When i use GET method then template content should be passed in the URL which has length restriction. We wanted to prepare email message which has more dynamic content.
Ultimately this service won't create any resource but still i forced to use POST method.
Am i missing something?
Rest standard missing?
Is there any better way of doing this?
Is there any restrictions on the length of get URL parameters?
Although there is no url limit in the standard, there is this old advice about keeping your urls under 2000 characters: What is the maximum length of a URL in different browsers?
To the point: in your case sending a POST request with all data in the body is the best solution. Putting email body fragments, or anything that huge (if I understand correctly) into a url is very ugly :). Even if the request does not change anything on the server technically, you should use POST, yes.
You need to create a new API which supports http get method, because one API can't receive more than on http method.
As you pointed out, in REST the POST method is thought of creating a new resource. In your case a new resource "message" is generated indeed by posting the content even if you do not keep it on the server.
But you are using POST on a template! This should create a new template. To resolve this, add a subresource to the template resource so you can express that it is a message that is created.
I would even extend the URL by adding a "template" after the "v1" to make more explicit that it is the "template" resouce on the first level.
The only change necessary for that would be to modify the URL like this:
URL pattern = /messagegenerator/v1/template/<templateID>/message
So you could have (even if you do not implement it now):
GET on /messagegenerator/v1/template/ -> Deliver a list of templates
POST on /messagegenerator/v1/template/ -> Create a new template
DELETE on /messagegenerator/v1/template/<templateID> -> Remove a template
PUT on /messagegenerator/v1/template/<templateID> -> Modify a template
GET on /messagegenerator/v1/template/<templateID>/message -> Deliver a list of messages
POST on /messagegenerator/v1/template/<templateID>/message -> Create a new message
DELETE on /messagegenerator/v1/template/<templateID>/message/<messageID> -> Remove a message
PUT on /messagegenerator/v1/template/<templateID>/message/<messageID> -> Modify a message
So you could even manage and return old messages if you saved and assigned them an ID!
I am writing a mobile iOS application, which communicates with a Pyramid app on the backend. I am currently using Pyramid's built-in AuthTktAuthenticationPolicy.
I've met some speed bumps while attempting to authenticate via a mobile client (iPhone). For starters, how would I send and retrieve the auth_tkt cookie that is set by Pyramid.
I understand how this works with a web browser, but, if I want to send this "auth_tkt cookie" in the HTTP response, how can I accomplish this? How do I actually get the auth_tkt secret string. For example, what if I'd like to return it in the JSON body or a custom header of my choosing rather than as the cookie set by Pyramid's remember function?
Secondly, in future requests sent by the client what header do I set with the auth_tkt secret string so that Pyramid recognizes it and appropriately authenticates the client?
Using the Pyramid Helper Classes here, it looks like you can create your own auth_tkt and access it as well. Example from docs:
token = AuthTicket('sharedsecret', 'username',
os.environ['REMOTE_ADDR'], tokens=['admin'])
val = token.cookie_value()
The headers is a webob ResponseHeaders object, it derives from webob multidict. You can get it value by using this:
set_cookie = request.response.headers['set-cookie']
You can refer this link: webob multidict
Given a one page app that uses push state and RESTful backend, we can imagine accessing the listing of a resource at /resourceName (i.e. /users). So /users would create a formated list of users
Now the problem is that this resource JSON or XML feed should also be mapped to /resourceName, so if boot form my application entry point at / then all is good, when navigating to /users the JS router can trigger a Ajax call that get the JSON data. Now the problem is if the URL is pointing directly at /users then i will land on a JSON feed instead of the actual listing. I could route all call to a main entry point and then let the JS router do the work though if i do so the AJAX call to fetch JSON wil brake.
I remember a while ago people adding .json to their json request, or even a GET parameter ?format=json and then having the controller taking different actions. I find that somewhat hacky.. Are there any other ways to go about this?
For that matter i am using laravel4 backend and backboneJS
I think the .json on the end of the request is the best approach. the other approach could be to create a separate endpoint endpoint for api request api.mydomain.com vs www.mydomain.com
What method you use to get a different response depends on how you'd like to go about it. Since you're asking about an opinionated topic (There is no one right answer), here's some options you can explore.
First, here's a good read from Apigee on API design, which covers what I'll write about here. See page 20 on "Support multiple formats"
The Rails way: Append a .json, .xml or other extension at the end of your request and handle that code within Laravel (You may want to use the "before" filter to check the request or Laravel's excellent route parameters, which allow the use of regex to define the route).
You can check the "accept" header in the request and set that header in your ajax calls to "application/json" instead of the default "application/html" to inform your application which format to use in its response. Again, the before or after filters may come in handy to check the request and define the response as appropriate
Create a query string `?format=json" or similar. Same comments as in point 1.
Laravel doesn't have built-in methods to change the response for you. You can, however, fairly easily detect what's being asked and choose which format to return in. It does take some thinking about how you want to accomplish that, however.
Some options off the top of my head:
Use the "before" or "after" filter to check what the request "wants" for a format, and do some transformations on the response to make that work
Extend the request and response class to "automate" this (request class to detect format, response class to transform the response to the correct format)
Hope that helps
It's valid to say which representation do you want. E.g. JSON, XML or binary, depends on what you want and which serializers have you developed.
You framework should support either setting of default representation or if you provide some mapping URL -> method you should be able to say which representation you are going to return - also either by default or taken within some object which represents your request.
I ended up using different endpoints as suggested by #Aaron Saunders. In laravel 4 this is dumb easy to implement using group routes:
app.php:
'domain' => 'whatever.dev',
routes.php:
define('APP_DOMAIN', 'app.' . Config::get('app.domain'));
define('API_DOMAIN', 'api.' . Config::get('app.domain'));
Route::group(array('domain' => API_DOMAIN), function()
{
// API ROUTES
});
Route::group(array('domain' => APP_DOMAIN), function()
{
// VIEW ROUTES
});
Beautiful!