Finch endpoint to support jsonp? - jsonp

I have a RESTFul service written in Finch framework with multiple endpoints. Some of the endpoints needs to support JSONP for cross domain requests. By checking the source code of Finch it looks like there is not an easy way of doing so. I've found this page kind of related but not quite knowing the details.
https://groups.google.com/forum/#!topic/finaglers/nAaCfOiLp1w
Can someone give me some guideline/example ?
My return value want to be look like:
{
ids:[id1,id2,id3...idn]
}

Not going into the details on why JSONP considered insecure (I assume you know that already), the Finaglers thread you're referencing mentions JsonpFilter that can be applied to an HTTP service returning JSON to "upgrade" it to JSONP.
Here is a small example on how to wire this filter with Finch's endpoint.
import com.twitter.finagle.Http
import com.twitter.finagle.http.filter.JsonpFilter
import io.finch._
import io.finch.circe._
val endpoint: Endpoint[Map[String, String]] = get("jsonp") {
Ok(Map("foo" -> "bar"))
}
val service = endpoint.toServiceAs[Application.Json]
Http.server.serve(":8080", JsonpFilter.andThen(service))
JsonpFilter is dead simple. It checks the returned HTTP payload and it's a JSON string, it wraps it with a call to a function whose name is passed in the callback query-string param (and changes the content-type to application/javascript correspondingly). Using httpie, this would look as:
$ http :8081/jsonp
HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Length: 39
Content-Type: application/json
{
"foo": "bar"
}
$ http :8080/jsonp?callback=myfunction
HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Length: 56
Content-Type: application/javascript
/**/myfunction({"foo":"bar"});

Related

send request not showing in rest client

I have installed rest client extension in vs code, but when I create .rest file and make some requests I don’t see the send request link
GET http://localhost:3000/signin
You can add three # symbol after each request like below:
POST http://localhost:8800/api/carts/
Content-Type: application/json; charset=utf-8
{
"productId": "63c00763e65ebde449e9b411",
"quantity": "1"
}
3 '###' here
GET http://localhost:8800/api/carts/

Google Cloud Function injecting 'Cache-Control: Private' header in response to Bingbot User Agent independent of function code

We have a Google Cloud Function in live, which is essentially returning the correct redirects for us from a now-defunct site using a very simple Python script, backed by a CDN which is caching the responses to avoid triggering the function more than necessary.
We're not having any problems with how the function itself is working, however we have noticed that in response to a specific User-Agent (Bingbot) being passed with the request, Google Cloud Function is injecting a Cache-Control: Private header into the response independent of the function code (which does not specify a Cache-Control header inside the 301 response it sends back). This is causing all requests from Bingbots to be passed to the backend every time, causing our cloud function usage to be much higher than it would ordinarily be and incurring higher costs.
This also causes changes to Content and Transfer Encoding, although we are less concerned about this.
We tested this by stripping out the User-Agent header at the CDN level before the request to the backend (the function) and confirmed that without the Bingbot headers we get 0 persistent passes; allowing the header back through recreated the issue of far more Passes than we should be seeing.
We've begun stripping all User-Agent headers at this point which has solved the issue on a shallow basis, but we are concerned that this is undocumented behaviour and we have no information about when Cloud Functions may in other circumstances inject or manipulate response headers in response to request headers.
To confirm this isn't coming from our Python script, the relevant portion returning our response is as follows:
try:
return flask.redirect(redirect_dict[request.path], code=301)
except:
return flask.redirect(os.environ.get('FALLBACK_URL'), code=301)
Curl with Bingbot UA (actual URL & host obscured):
curl -v -X GET $function/$path -H 'User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)' -H $host
And the relevant response:
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html; charset=utf-8
< Function-Execution-Id: jzlrm3k4ndhv
< Location: $redirectURL
< X-Cloud-Trace-Context: 83841aa8390d4ea4c1c8349c3aca21be
< Content-Encoding: gzip
< Date: Mon, 20 May 2019 13:02:22 GMT
< Server: Google Frontend
< Cache-Control: private
< Alt-Svc: quic=":443"; ma=2592000; v="46,44,43,39"
< Transfer-Encoding: chunked
Without Bingbot UA, the response is:
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html; charset=utf-8
< Function-Execution-Id: t8frc9wsdvzp
< Location: $redirectURL
< X-Cloud-Trace-Context: 1f817eecdc84ad4a7542fba5898caf50;o=1
< Date: Mon, 20 May 2019 13:02:37 GMT
< Server: Google Frontend
< Content-Length: 319
< Alt-Svc: quic=":443"; ma=2592000; v="46,44,43,39"
We would expect responses to be the same as we are not injecting any cache-control headers in response to queries. Clearly varying the User Agent causes Google Cloud Functions to inject additional headers, vary encoding and otherwise transform responses. The concern is that there is no documentation or other information about this (unless I've missed it). If someone could point me at any kind of explanation, or if someone from Google could explain why this happens and any other settings we could use to prevent it, that would be the ideal outcome here.

.NET Core API Request does not match a supported file type

I just want to make sure I have no issue here. Does anybody know what causes the
2017-03-17 07:59:17.5838|1|Microsoft.AspNetCore.Hosting.Internal.WebHost|INFO|Request starting HTTP/1.1 GET http://192.168.20.57:8081/hardware/configuration/active application/json
2017-03-17 07:59:17.5868|4|Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware|DEBUG|The request path /hardware/configuration/active does not match a supported file type
I'm exposing the Web API by Kestrel only (no IISIntegration).
The request header contains
GET /hardware/configuration/active HTTP/1.1
Accept: application/json, text/plain, */*
Content-Type: application/json
Defining
[Produces("application/json")]
explicitly in my controller has no effect.
Set StaticFileOptions.ServeUnknownFileTypes to true:
app.UseStaticFiles(new StaticFileOptions()
{
FileProvider = new PhysicalFileProvider("mypath"),
ServeUnknownFileTypes = true // <<<<<<
});
or find out where the unknown types can be extended (please let me know in the latter case).
After the request comes in by kestrel (which is your first log row).
It first goes through a middleware pipeline until it reaches the WebApi middleware.
As you can see in the second logging row: Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware. It reached the StaticFileMiddleware and not the WebApi Middleware.
Probably the staticFileHandler finds a file there in the wwwroot folder and thus returns this message? Or Even before it tries to check the filesystem it checks if it is an allowed/known file extension and this is not the case, thus this second log message.

batch request on google group api with oauth2-playground

I'm trying to understand (and eventually make it work) batch request on the google group API.
With Oauth2 Playground I know how to perform a single request with:
on step 1 authorised API are
https://www.googleapis.com/auth/admin.directory.group.member.readonly
https://www.googleapis.com/auth/admin.directory.group.member
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.group
on step 3 I'm making a post request with:
request URI: https://www.googleapis.com/admin/directory/v1/groups/mytestgroup#domain.ext/members
and the body is:
{
"email": "lya#example.com",
"role": "MEMBER"
}
So far so good, but now I'm trying to do the same in a batch request
I tried to follow the explanation here:
https://developers.google.com/admin-sdk/directory/v1/guides/batch#example
but I didn't understood everything so I went there:
https://developers.google.com/storage/docs/json_api/v1/how-tos/batch
So I did the following request with, on step 1 the same API but on step 3:
a post request to:
https://www.googleapis.com/batch
with a custom content-type:
the header is now
multipart/mixed; boundary="batch_foobarbaz"
and in the body request:
--batch_foobarbaz
Content-Type: application/http
POST /admin/directory/v1/groups/mytestgroup#domain.ext/members HTTP/1.1
Content-Type: application/json
content-length: 58
{
"email": "liz#example.com",
"role": "MEMBER"
}
--batch_foobarbaz--
I also tried different variants but I never get to do the correct request, I systematically get 400 error.
Can someone help me with that, I don't know what I can do to correct that.
Thanks in advance, Harold
Okey sorry for the inconvenience, I found my answer. Here is what I've done:
on step 1 authorised API are:
https://www.googleapis.com/auth/admin.directory.group.member.readonly
https://www.googleapis.com/auth/admin.directory.group.member
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.group
on step 3 I'm making a post request with:
https://www.googleapis.com/batch
with a custom content-type: multipart/mixed; boundary="batch_foobarbaz"
body request:
--batch_foobarbaz
Content-Type: application/http
Content-Transfer-Encoding: binary
POST /admin/directory/v1/groups/mytestgroup#domain.ext/members HTTP/1.1
Content-type: application/json
{"email": "ldn#example.com", "role": "MEMBER"}
--batch_foobarbaz--
the important part here are the carriage return. They are mandatory after Content-Transfer-Encoding: binary and after Content-type: application/json

What is reponse.d when returning data from a WCF Service with ContentType of "application/json"?

I have a WCF service that has webHttpBinding and has enableWebScript turned on in it's endpoint behavior configuration.
The response from the service looks something like this
HTTP/1.1 200 OK
Date: Fri, 23 Oct 2009 20:09:02 GMT
Server: Microsoft-IIS/6.0
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: application/json; charset=utf-8
Content-Length: 25
{"d":{"__type":"SOMETYPE", ... }}
Its using HTTP 1.1 and so there are the standard headers. The contentType is set to be applciation/json which also makes sense. In the message body (the JSON part), everything is enclosed in an envelope titled "d".
What is that? Who defines that protocol? Is it something specific to WCF?
I couldn't find that defined in any of the protocols involved or the definition of the "application/json" contentType.
Thanks
That is ASP.NET AJAX specific and is caused by applying the WebScriptEnablingBehavior (enableWebScript in config) to your endpoint. The wrapper is required on both input and output and there are also special behaviors added around exception handling.
If you want "pure" JSON, you should remove the WebScriptEnablingBehavior and just use WebHttpBehavior (webHttp in config). Then just make sure you explicitly set the Request/ResponseFormat properties on your WebGet/InvokeAttributes.