How to get http headers on a service in Jolie Programming Language - http

I have a service written in Jolie, where I want to extract the http headers on request. In the same way the request.id can be printed out, I would like to print the headers. There is a try on the bold letter down in the code. Here the code:
execution { concurrent }
inputPort UserDB_Service {
Location: "socket://localhost:8002/"
Protocol: http { .format = "json"}
Interfaces: Users, ShutdownInterface, ConnectionPool
}
outputPort DB_Connector {
Location: "socket://localhost:1000/"
Protocol: sodep
Interfaces: ConnectionPool
}
init
{
connectionConfigInfo#DB_Connector()(connectionInfo);
connect#Database(connectionInfo)()
}
main
{
//Example: http://localhost:8002/retrieve?id=1
[ retrieve(request)(response) {
query#Database(
"select * from users where user_id=:id" {
.id = request.id
}
)(sqlResponse);
println#Console( "You have requested the user_id: " + request.id)();
**println#Console( "Request Headers: " + response.format)();**
if (#sqlResponse.row == 1) {
response -> sqlResponse.row[0]
}
} ]
}
Thanks for the help.

I did not understand if you know which headers you want to have in the inbound request or if you just want to print the whole http message for debugging purposes. It is quick in both cases, I report both solutions :)
In the first case you can set the headers parameter of the http protocol for the inputPort to include in the request message also the content of a specific header, e.g.,
http {
.headers.format = "format";
}
and then you can inspect the value in the usual way
println#Console( request.format )()
In the second case, you can use
http {
.debug = true;
.debug.showContent = true
}
to see the log of all http requests and responses and their bodies.
These and further info on protocols and in particular the http protocol is in the documentation of the Jolie site.

I put the output here again. I wonder if it is possible to extract the "iv-user: g47257" header, which I have injected by using Fiddler. Thanks again for the help.
The headers are like this (better format).
INFO: [UserDB_crud.ol] [HTTP debug] Receiving:
HTTP Code: 0
Resource: /retrieve?id=1
--> Header properties
iv-user: g47257
accept-language: en-US,en;q=0.8,da;q=0.6,es;q=0.4
host: localhost:8002
upgrade-insecure-requests: 1
connection: keep-alive
cache-control: max-age=0
accept-encoding: gzip, deflate, sdch
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp
,*/*;q=0.8
user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTM
L, like Gecko) Chrome/48.0.2564.116 Safari/537.36
You have requested the user_id: 1
mar. 10, 2016 2:30:44 PM jolie.Interpreter logInfo
INFO: [UserDB_crud.ol] [HTTP debug] Sending:
HTTP/1.1 200 OK
Server: Jolie
X-Jolie-MessageID: 0
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Content-Length: 72
?V*H,..?/JQ?R*I-.Q?Q*-N-??♦
↑?(?%?"dRs‼3s?\►?????T♂ %??WE
mar. 10, 2016 2:30:44 PM jolie.Interpreter logInfo
INFO: [UserDB_crud.ol] [HTTP debug] Receiving:
HTTP Code: 0
Resource: /favicon.ico
--> Header properties
iv-user: g47257
referer: http://localhost:8002/retrieve?id=1
accept-language: en-US,en;q=0.8,da;q=0.6,es;q=0.4
host: localhost:8002
connection: keep-alive
cache-control: no-cache
pragma: no-cache
accept-encoding: gzip, deflate, sdch
user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTM
L, like Gecko) Chrome/48.0.2564.116 Safari/537.36
accept: */*
mar. 10, 2016 2:30:44 PM jolie.Interpreter logWarning
WARNING: [UserDB_crud.ol] Received a message for operation favicon.ico, not specified in the input port at the receiving service. Sending IOException to the caller.
mar. 10, 2016 2:30:44 PM jolie.Interpreter logInfo
INFO: [UserDB_crud.ol] [HTTP debug] Sending:
HTTP/1.1 200 OK
Server: Jolie
X-Jolie-MessageID: 0
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Content-Length: 102
?VJ-*?/R??V?M-.NLOU?R??w?HN-(???S?QJ?O☺?→←↓↑↑?(?$?$???%?d?(?↨?▬%?¶Z)?%?e&???☺ ??Z ?yd?Y

I re-post my last comment here since other people faced the same difficulties found by Efrin but might miss the solution I posted as a comment.
You can inspect the headers of a HTTP request as shown in the code below
include "console.iol"
inputPort Me {
Location: "socket://localhost:8000"
Protocol: http { .headers.iv_user = "ivUser" }
RequestResponse: myRequest
}
main {
myRequest( request )(){ println#Console( request.ivUser )() }
}
Remember that, as reported in the documentation, Jolie http.headers parameters map - in header names with _, e.g., in your case, header iv-user becomes iv_user in the Jolie HTTP protocol parameters.
Besides the description and code found in the Jolie documentation, you can find further examples and a more thorough explanation on how the HTTP protocol works in Jolie in its presentation paper wrote by Montesi https://doi.org/10.1016/j.scico.2016.05.002.

Related

make flask return response header http1.1 instead http1.0 [duplicate]

I have a jQuery Ajax call, like so:
$("#tags").keyup(function(event) {
$.ajax({url: "/terms",
type: "POST",
contentType: "application/json",
data: JSON.stringify({"prefix": $("#tags").val() }),
dataType: "json",
success: function(response) { display_terms(response.terms); },
});
I have a Flask method like so:
#app.route("/terms", methods=["POST"])
def terms_by_prefix():
req = flask.request.json
tlist = terms.find_by_prefix(req["prefix"])
return flask.jsonify({'terms': tlist})
tcpdump shows the HTTP dialog:
POST /terms HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/json; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://127.0.0.1:5000/
Content-Length: 27
Pragma: no-cache
Cache-Control: no-cache
{"prefix":"foo"}
However, Flask replies without keep-alive.
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 445
Server: Werkzeug/0.8.3 Python/2.7.2+
Date: Wed, 09 May 2012 17:55:04 GMT
{"terms": [...]}
Is it really the case that keep-alive is not implemented?
The default request_handler is WSGIRequestHandler.
Before app.run(), Add one line,
WSGIRequestHandler.protocol_version = "HTTP/1.1"
Don't forget from werkzeug.serving import WSGIRequestHandler.
Werkzeug's integrated web server builds on BaseHTTPServer from Python's standard library. BaseHTTPServer seems to support Keep-Alives if you set its HTTP protocol version to 1.1.
Werkzeug doesn't do it but if you're ready to hack into the machinery that Flask uses to instantiate Werkzeug's BaseWSGIServer, you can do it yourself. See Flask.run() which calls werkzeug.serving.run_simple(). What you have to do boils down to BaseWSGIServer.protocol_version = "HTTP/1.1".
I haven't tested the solution. I suppose you do know that Flask's web server ought to be used for development only.

Why is my AJAX result not ETag-cached (no If-None-Match)?

Here is my AJAX function:
function ajax(url, data) {
return new Promise((resolve, reject) => {
$.ajax({
url: "https://xxx",
data: data,
method: 'POST',
timeout: 50000,
cache: true,
ifModified: true,
crossDomain: true,
success: (data, textStatus, jqXHR) => {
if (data == '#fail#') reject(data);
else {resolve(data);}
},
error: (jqXHR, textStatus, errorThrown) => {
reject(errorThrown);
}
});
});
}
As observed in Chrome -> Network(F12), this is the response header from the server:
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: text/html; charset=utf-8
Content-Length: 3
ETag: W/"3-R7zlx09Yn0hn29V+nKn4CA"
Date: Fri, 06 Apr 2018 11:39:41 GMT
Connection: keep-alive
The request header is always identical, even in subsequent calls:
POST /register HTTP/1.1
Host: xxx:60001
Connection: keep-alive
Content-Length: 0
Accept: */*
Origin: http://localhost:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Referer: http://localhost:8000/index.html
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Shouldn't Chrome, upon receiving an ETag header, cache the resource and set the 'If-None-Match' header on subsequent calls to the same URL? Shouldn't I obtain a status code of 304 instead of 200 as the returned content is the same?
The calls to the resources in other servers such as the Google Map server do return 304 sometimes though.
This confirms that caching is generally limited to GET request methods only:
However, common HTTP caches are typically limited to caching responses to GET and may decline other methods. The primary cache key consists of the request method and target URI (oftentimes only the URI is used as only GET requests are caching targets)
This is also confirmed in a post in StackOverflow here.

Asp.net on Azure cannot login facebook? Location: /Account/ExternalLoginCallback?error=access_denied

I followed the link https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-how-to-configure-facebook-authentication to set up Facebook login.
In the https://developers.facebook.com/apps, the "Valid OAuth redirect URIs" has the following URIs
https://myapp.azurewebsites.net/signin-facebook
https://myapp.azurewebsites.net/.auth/login/facebook/callback
However, the site cannot login - the login page just stays. Type an Url https://myapp.azurewebsites.net/event will always redirect to https://myapp.azurewebsites.net/Account/Login?ReturnUrl=%2Fevent.
The following is the Net traffic captured by fiddler. It seems the request is denied when GET https://myapp.azurewebsites.net/signin-facebook?code=.... (Response: Location: /Account/ExternalLoginCallback?error=access_denied)
------------------------------------------------------------------
GET https://www.facebook.com/dialog/oauth?response_type=code&client_id=365322087148601&redirect_uri=https%3A%2F%2Fmyapp.azurewebsites.net%2Fsignin-facebook&scope=&state=E4J6p7jhJVr2YT1SYqxzHKoUJ1u04QtfVu8UUtgoRzK8xPfXvHnWSFJE5TGKOn9AoqVQkvGZHzakiNoTme2bQBm27n1riQTPTCLNrIoybUxhV-wXpyUDYrkXVawTs0JMtTOW1UK2gv_1YJ_A9EkbvPSZMXN-NW56vF2lq8d-9iPG7fTv41CGV3-0bVV2dAEW86gyO70VLVdQ5X2byye_XFS3XNkhtVJEbfXio_RMRvE HTTP/1.1
Accept: text/html, application/xhtml+xml, image/jxr, */*
Referer: https://myapp.azurewebsites.net/Account/Login
Accept-Language: en-US,en;q=0.8,zh-Hans-CN;q=0.5,zh-Hans;q=0.3
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: www.facebook.com
Cookie: fr=0RObsAfMX8N2oDE0P.AWUijY5j4ajj3MWCbj2nVPEp4Go.BY9tIg.oW.Fj2.0.0.BY-AuR.AWU2VfKJ; datr=INL2WBkTq1-aa6V7IMJUUMMw; dats=1; sb=JNL2WJ2XCIs_K6QaFHEcvbTM; c_user=100000343225510; xs=251%3A-D7EtOmwXRbYlQ%3A2%3A1492570660%3A12220; pl=n; lu=ggNZWbJ4ElBZhc5tOVdylWWA; presence=EDvF3EtimeF1492652361EuserFA21B00343225510A2EstateFDutF1492652361094CEchFDp_5f1B00343225510F195CC
HTTP/1.1 302 Found
Location: https://myapp.azurewebsites.net/signin-facebook?code=AQC2JMYoeLmJAHtkTiHMTEckID_cdoJZ0eFkuffNCSh-XDzgZWCm-cJbDyIMJaLEa-mLApgU54MoppjOS0CH3b6jWCN-VDXsqq7z-6TALE35OdralWJRFSZQs7k-_4qBk4Vl8HmeW0INO5V4NL9nVU1tlDSqF6PoAN4Dee5DvvJyr_w_-ZE2ZG_dfY5zcq2-G9dNcqVGDs3YWzDQfP3VmWu-4kFZ3YUC8ENfFoUZPw8uvOBGPEgr_92aK8cQJnLXd1k98jCKb-sIzQHB9XCfUFW1QrMeww4EqvTvINl0Pu0O8l--M-zATFoMnQW6et8RRhBarAbmYSVMGCkClEFUDPe9Mcn8-qsFr1WBv4kqtLrnSA&state=E4J6p7jhJVr2YT1SYqxzHKoUJ1u04QtfVu8UUtgoRzK8xPfXvHnWSFJE5TGKOn9AoqVQkvGZHzakiNoTme2bQBm27n1riQTPTCLNrIoybUxhV-wXpyUDYrkXVawTs0JMtTOW1UK2gv_1YJ_A9EkbvPSZMXN-NW56vF2lq8d-9iPG7fTv41CGV3-0bVV2dAEW86gyO70VLVdQ5X2byye_XFS3XNkhtVJEbfXio_RMRvE#_=_
Expires: Sat, 01 Jan 2000 00:00:00 GMT
facebook-api-version: v2.8
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=15552000; preload
X-Frame-Options: DENY
Cache-Control: private, no-cache, no-store, must-revalidate
Pragma: no-cache
public-key-pins-report-only: max-age=500; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="; pin-sha256="q4PO2G2cbkZhZ82+JgmRUyGMoAeozA+BSXVXQWB8XWQ="; report-uri="http://reports.fb.com/hpkp/"
X-XSS-Protection: 0
Content-Type: text/html
X-FB-Debug: BOC8IkjZ4va1buTLdHl+OgLKK4ymT3oyi4SALf8bnAQx2MDqHkCvmTGsTMngZazRs0dFZ6SSHYSi0U6mcbaQNw==
Date: Thu, 20 Apr 2017 01:42:19 GMT
Connection: keep-alive
Content-Length: 0
------------------------------------------------------------------
GET https://myapp.azurewebsites.net/signin-facebook?code=AQC2JMYoeLmJAHtkTiHMTEckID_cdoJZ0eFkuffNCSh-XDzgZWCm-cJbDyIMJaLEa-mLApgU54MoppjOS0CH3b6jWCN-VDXsqq7z-6TALE35OdralWJRFSZQs7k-_4qBk4Vl8HmeW0INO5V4NL9nVU1tlDSqF6PoAN4Dee5DvvJyr_w_-ZE2ZG_dfY5zcq2-G9dNcqVGDs3YWzDQfP3VmWu-4kFZ3YUC8ENfFoUZPw8uvOBGPEgr_92aK8cQJnLXd1k98jCKb-sIzQHB9XCfUFW1QrMeww4EqvTvINl0Pu0O8l--M-zATFoMnQW6et8RRhBarAbmYSVMGCkClEFUDPe9Mcn8-qsFr1WBv4kqtLrnSA&state=E4J6p7jhJVr2YT1SYqxzHKoUJ1u04QtfVu8UUtgoRzK8xPfXvHnWSFJE5TGKOn9AoqVQkvGZHzakiNoTme2bQBm27n1riQTPTCLNrIoybUxhV-wXpyUDYrkXVawTs0JMtTOW1UK2gv_1YJ_A9EkbvPSZMXN-NW56vF2lq8d-9iPG7fTv41CGV3-0bVV2dAEW86gyO70VLVdQ5X2byye_XFS3XNkhtVJEbfXio_RMRvE HTTP/1.1
Accept: text/html, application/xhtml+xml, image/jxr, */*
Referer: https://myapp.azurewebsites.net/Account/Login
Accept-Language: en-US,en;q=0.8,zh-Hans-CN;q=0.5,zh-Hans;q=0.3
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: myapp.azurewebsites.net
Cookie: __RequestVerificationToken=49xMNw5ePC60qAaVBtxq5TAbkgpGbkcPyb5OcWmO0CYNstOX7vUQJAST80cvsFM16l0USNgUCr9b5RCn3cnXXlsGhpz33rme4A_HRw1QFNY1; ARRAffinity=f86b281b78014bea7ff499f4d5d3d562aafe8f1cf9e24d7ef4dc3d48d94a9c32; .AspNet.Correlation.Facebook=hcA83RJONYyZTzuT0I3kTRJM6DTK9OUsmmrQKV_mAkU
HTTP/1.1 302 Found
Content-Length: 0
Location: /Account/ExternalLoginCallback?error=access_denied
Server: Microsoft-IIS/8.0
Set-Cookie: .AspNet.Correlation.Facebook=; expires=Thu, 01-Jan-1970 00:00:00 GMT
X-Powered-By: ASP.NET
Date: Thu, 20 Apr 2017 01:42:20 GMT
Startup.Auth.cs:
public partial class Startup
{
// For more information on configuring authentication, please visit http://go.microsoft.com/fwlink/?LinkId=301864
public void ConfigureAuth(IAppBuilder app)
{
// Configure the db context, user manager and role manager to use a single instance per request
app.CreatePerOwinContext(ApplicationDbContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
app.CreatePerOwinContext<ApplicationRoleManager>(ApplicationRoleManager.Create);
// Enable the application to use a cookie to store information for the signed in user
// and to use a cookie to temporarily store information about a user logging in with a third party login provider
// Configure the sign in cookie
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
Provider = new CookieAuthenticationProvider
{
// Enables the application to validate the security stamp when the user logs in.
// This is a security feature which is used when you change a password or add an external login to your account.
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
validateInterval: TimeSpan.FromMinutes(30),
regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
}
});
app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
// Enables the application to temporarily store user information when they are verifying the second factor in the two-factor authentication process.
app.UseTwoFactorSignInCookie(DefaultAuthenticationTypes.TwoFactorCookie, TimeSpan.FromMinutes(5));
// Enables the application to remember the second login verification factor such as phone or email.
// Once you check this option, your second step of verification during the login process will be remembered on the device where you logged in from.
// This is similar to the RememberMe option when you log in.
app.UseTwoFactorRememberBrowserCookie(DefaultAuthenticationTypes.TwoFactorRememberBrowserCookie);
// Uncomment the following lines to enable logging in with third party login providers
//app.UseMicrosoftAccountAuthentication(
// clientId: "",
// clientSecret: "");
//app.UseTwitterAuthentication(
// consumerKey: "",
// consumerSecret: "");
app.UseFacebookAuthentication(
appId: ".....",
appSecret: ".....");
//app.UseGoogleAuthentication();
}
}
Update:
After updated Microsoft.Owin.Security.Facebook, facebook login prompted me to register a new user. However, it still redirect to login page? The following is the http traffic.
POST https://myapp.azurewebsites.net/Account/ExternalLogin?ReturnUrl=%2Fevent HTTP/1.1
Accept: text/html, application/xhtml+xml, image/jxr, */*
Referer: https://myapp.azurewebsites.net/Account/Login?ReturnUrl=%2Fevent
Accept-Language: en-US,en;q=0.8,zh-Hans-CN;q=0.5,zh-Hans;q=0.3
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: myapp.azurewebsites.net
Content-Length: 196
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: __RequestVerificationToken=49xMNw5ePC60qAaVBtxq5TAbkgpGbkcPyb5OcWmO0CYNstOX7vUQJAST80cvsFM16l0USNgUCr9b5RCn3cnXXlsGhpz33rme4A_HRw1QFNY1; ARRAffinity=f86b281b78014bea7ff499f4d5d3d562aafe8f1cf9e24d7ef4dc3d48d94a9c32; .AspNet.ApplicationCookie=VkuppVPkn0nPbkYf5aSoSKrYsJVWusdEU4TKvf_bPajqbd7gMexZ4muf43ZnpSOwt9P6L60Lc_7VBWZu8Q41eIN2qw3vmhdcAC3gypOhFrQ57T-ymAyJX838uGjsjE3zw_RlVr1kLbyomB5xFVz5azv3nMCm4DDGadGQTSrPdEOQ54GVTQiDJJ9wi4vAd7Cc96ssc4J4x9HrWRIwdZiorubCJpyd1SUeDd6MkZTQgdxGPR42NBwr1CH7DDymU2fJSMw7Dw6Qi5IDNYwFL32J0rsc_5ji_VxvbUBhJZDFGwOxsQ5cFzm0k-XuqJB5zH1aS-6WvQ97sAbu4kQOt0BCZc3EhBAy9c5gmRmq1HyB-NiDwxhbpcS1e57M_9yNmdh8l9phHpnrthk2JNxzyom1Ni-nTbkbZsFdQ2SwuzuPaKS_R1IvXG57q7GM3QEzzTkjsZmuEPCaP5IvFfjISH8kVFBzCnoCoYkvjTKNsfG05VY
HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 0
Location: https://www.facebook.com/v2.8/dialog/oauth?response_type=code&client_id=365322087148601&redirect_uri=https%3A%2F%2Fmyapp.azurewebsites.net%2Fsignin-facebook&scope=&state=wq_uw7UGAFosxcCkR_Oa7P9gyBQeE4DbW92-YZN0tgOFzlOTLeFxDsaVVmH9SsEY6rkZb3zU4ZRBjcp3nQf-b4V-lbXSihHBIzol77_SiBOX7b-GI8iDtPfp9VFuXbhXZWn--GY5xhjOLXnMCu1idq-Y53qMLm_mhX_oOFuOqgyLmqz35Cf3ardNKUT9tdXUyrLOkOCndQ3R2KSWx_FJ0qzptM6J0IyCvk-JwFkEKvjAh3-mgopTgnIKP-LHBL2Z
Server: Microsoft-IIS/8.0
Set-Cookie: .AspNet.Correlation.Facebook=dfeXeK1QG0fHz_lgWH9nLhCT4Zw0USACEAyA0oAZzZ8; path=/; secure; HttpOnly
X-AspNetMvc-Version: 5.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Thu, 20 Apr 2017 03:49:27 GMT
------------------------------------------------------------------
GET https://www.facebook.com/v2.8/dialog/oauth?response_type=code&client_id=365322087148601&redirect_uri=https%3A%2F%2Fmyapp.azurewebsites.net%2Fsignin-facebook&scope=&state=wq_uw7UGAFosxcCkR_Oa7P9gyBQeE4DbW92-YZN0tgOFzlOTLeFxDsaVVmH9SsEY6rkZb3zU4ZRBjcp3nQf-b4V-lbXSihHBIzol77_SiBOX7b-GI8iDtPfp9VFuXbhXZWn--GY5xhjOLXnMCu1idq-Y53qMLm_mhX_oOFuOqgyLmqz35Cf3ardNKUT9tdXUyrLOkOCndQ3R2KSWx_FJ0qzptM6J0IyCvk-JwFkEKvjAh3-mgopTgnIKP-LHBL2Z HTTP/1.1
Accept: text/html, application/xhtml+xml, image/jxr, */*
Referer: https://myapp.azurewebsites.net/Account/Login?ReturnUrl=%2Fevent
Accept-Language: en-US,en;q=0.8,zh-Hans-CN;q=0.5,zh-Hans;q=0.3
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: www.facebook.com
Cookie: fr=0RObsAfMX8N2oDE0P.AWUijY5j4ajj3MWCbj2nVPEp4Go.BY9tIg.oW.Fj2.0.0.BY-AuR.AWU2VfKJ; datr=INL2WBkTq1-aa6V7IMJUUMMw; dats=1; sb=JNL2WJ2XCIs_K6QaFHEcvbTM; c_user=100000343225510; xs=251%3A-D7EtOmwXRbYlQ%3A2%3A1492570660%3A12220; pl=n; lu=ggNZWbJ4ElBZhc5tOVdylWWA; presence=EDvF3EtimeF1492652361EuserFA21B00343225510A2EstateFDutF1492652361094CEchFDp_5f1B00343225510F195CC
HTTP/1.1 302 Found
Location: https://myapp.azurewebsites.net/signin-facebook?code=AQCGF2xmMpxqeJOvGi0ngPWLVPqxKZL19gdGPeZdYjQ0k6S-Ta_WS0VxOBxR7wcz70IzHkeC-jQw8KAy7NNP-9m0_atTD6OJYjFZpbnAyixkg7-2r6_B5MR3_nzSBVqc8orXBeBy4KbcG0pgcW6AYGOX1inJaXixCbvypqK5JSgj8RTjbnTd8OmMMzVhC6QBpuViHEcnwOKMx3YgaOEyV9GXwr39EBY-WvcDlu1b__L7vSD9y1VA5jGfAX7jRTmXOOOPrgU-KVOnvqrAUj4RgfpS2YqEFa59t9k00emP2L2FRq94HHBzZshI3dwN0kFH6nVu1y8VKuGqgIDJqbkiXPj88kgbC612wocVpuST4Y0q2g&state=wq_uw7UGAFosxcCkR_Oa7P9gyBQeE4DbW92-YZN0tgOFzlOTLeFxDsaVVmH9SsEY6rkZb3zU4ZRBjcp3nQf-b4V-lbXSihHBIzol77_SiBOX7b-GI8iDtPfp9VFuXbhXZWn--GY5xhjOLXnMCu1idq-Y53qMLm_mhX_oOFuOqgyLmqz35Cf3ardNKUT9tdXUyrLOkOCndQ3R2KSWx_FJ0qzptM6J0IyCvk-JwFkEKvjAh3-mgopTgnIKP-LHBL2Z#_=_
Expires: Sat, 01 Jan 2000 00:00:00 GMT
facebook-api-version: v2.8
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=15552000; preload
X-Frame-Options: DENY
Cache-Control: private, no-cache, no-store, must-revalidate
Pragma: no-cache
public-key-pins-report-only: max-age=500; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="; pin-sha256="q4PO2G2cbkZhZ82+JgmRUyGMoAeozA+BSXVXQWB8XWQ="; report-uri="http://reports.fb.com/hpkp/"
X-XSS-Protection: 0
Content-Type: text/html
X-FB-Debug: ABkQtw3vY1sccWewy5h4luP2SmaMQXgOUnv2HfxKkMGR7VFV+3Jq7+HOsVnGAESUXqI7RT+raZ/CrCLo3U1JbQ==
Date: Thu, 20 Apr 2017 03:49:26 GMT
Connection: keep-alive
Content-Length: 0
There is a X-Frame-Options: DENY for the request of GET https://www.facebook.com/v2.8/dialog/oauth?response_type=code&client_id=....
I could encounter the same issue, after some searches I found that the facebook graph api did some changes. Here is the detailed info, you could refer to it:
Facebook Graph API has a force upgrade: Changes from v2.2 to v2.3
[Oauth Access Token] Format - The response format of https://www.facebook.com/v2.3/oauth/access_token returned when you exchange a code for an access_token now return valid JSON instead of being URL encoded. The new format of this response is {"access_token": {TOKEN}, "token_type":{TYPE}, "expires_in":{TIME}}. We made this update to be compliant with section 5.1 of RFC 6749.
Since the access_token returned with the JSON instead of the URL encoded, Microsoft.Owin.Security.Facebook prior to 3.1.0 could not handle this change. You need to upgrade Microsoft.Owin.Security.Facebook to 3.1.0 version, or you need to implement the FacebookAuthenticationOptions.BackchannelHttpHandler for a workaround to handle this change, for more details, you could refer to this similar answer.
UPDATE
As I known, X-Frame-Options indicates whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object>, I assumed that this header has no relation with your issue. Since your network packages are from your client, you could not see the processing when you use authorization_code to exchange the access_token from facebook. I recommended that you could run your web app on your local side and capture the packages as follows:
I have checked both update Microsoft.Owin.Security.Facebook to 3.1.0 and implement FacebookAuthenticationOptions.BackchannelHttpHandler by following this issue, both could work on my side and azure. In summary, you could get the authorization_code but failed to extract the access_token, I assumed that you need to clear/rebuild your project and make sure your project could work on your local side, then redeploy your project to web app (if you deploy the website via VS publish wizard, you could choose the "Remove additional files at destination" under Settings > File Publish Options or you could use KUDU to empty your web content).
UPDATE2
I have created a code sample AspDotNet-WebApplication-FacebookAuth with my facekbook app, you could try to run on your local side and make sure you could retrieve the access_token and get the logged user info as follows:

asp.net web api PUT method not supported

I am making a PUT request for a PersonController but it is not even reaching the controller. Instead I get following response from Server
{"message":"The requested resource does not support http method 'PUT'."}
But a get request GET /api/person is being served properly.
Here is the Person Controller
public class PersonController : ApiController
{
// GET: api/Person/5
[ResponseType(typeof(Person))]
public IHttpActionResult GetPerson(int id) {
//Served without any issues
}
// PUT: api/Person/5
[ResponseType(typeof(void))]
public IHttpActionResult PutPerson(int id, Person person) {
//Not reaching here!
}
}
Here is the PUT request as shown in fiddler
PUT http://localhost:xxxxx/api/person HTTP/1.1
Host: localhost:xxxxx
Connection: keep-alive
Content-Length: 38
Accept: application/json, text/javascript, */*; q=0.01
Origin: http://localhost:xxxxx
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36
Content-Type: application/json
DNT: 1
Referer: http://localhost:xxxxx/index.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,ms;q=0.6
{"id":0,"name":"Person 11","age":"11"}
And the Server Response
HTTP/1.1 405 Method Not Allowed
Cache-Control: no-cache
Pragma: no-cache
Allow: GET,POST
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?RDpcWGFuYWR1XFZTX1Byb2plY3RzXEJhY2tib25lSlNfUmVzdENhbGxzXEJhY2tib25lSlNfUmVzdENhbGxzLldlYlxhcGlccGVyc29u?=
X-Powered-By: ASP.NET
Date: Sat, 16 Aug 2014 09:20:46 GMT
Content-Length: 72
{"message":"The requested resource does not support http method 'PUT'."}
Clearly, the PUT request is rejected by the IIS Express. What is the correct way to configure the IIS Express (VS 2013) to allow PUT and DELETE requests at the project level.

Failing to set the user agent via httr::user_agent

Is there anything special I need to consider when trying to change the user agent via httr::user_agent in a httr::GET() call on MS Windows? I'm using R-3.1.0 and httr 0.3.
Following the example at ?user_agent, I'm getting these results:
url_this <- "http://httpbin.org/user-agent"
Standard user agent:
GET(url_this)
Response [http://httpbin.org/user-agent]
Status: 200
Content-type: application/json
{
"user-agent": "curl/7.19.6 Rcurl/1.95.4.1 httr/0.3"
}
Modified user agent:
GET(url_this, user_agent("Mozilla/5.0"))
Response [http://httpbin.org/user-agent]
Status: 200
Content-type: application/json
{
"user-agent": "curl/7.19.6 Rcurl/1.95.4.1 httr/0.3"
}
I had expected that the second call returns something closer to what I'm getting when visiting url_this in my browser:
{
"user-agent": "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"
}
What am I missing here? Also ran setInternet2(TRUE) first, but got identical results.
Very curious the help page ?user_agent suggests it should work. You can set a header explicitly and it does work
> GET("http://httpbin.org/user-agent", add_headers("user-agent" = "Mozilla/5.0"))
Response [http://httpbin.org/user-agent]
Status: 200
Content-type: application/json
{
"user-agent": "Mozilla/5.0"
}
but the example given in ?user_agent appears not to.
> GET("http://httpbin.org/user-agent", user_agent("Mozilla/5.0") )
Response [http://httpbin.org/user-agent]
Status: 200
Content-type: application/json
{
"user-agent": "curl/7.19.6 Rcurl/1.95.4.1 httr/0.3"
}
>
It is returning
> httr:::default_ua()
[1] "curl/7.19.7 Rcurl/1.95.4.1 httr/0.3"
My ISP was also doing something funky so you may need:
GET("http://httpbin.org/user-agent", add_headers("user-agent" = "Mozilla/5.0", "Cache-Control" = "no-cache"))

Resources