I am hoping to get some clarification on the expected behavior of a SIP Proxy when proxying 401 responses from a downstream UAS.
Our SIP Proxy is configured to proxy requests downstream in a round-robin fashion. If the downstream UAS responds to an INVITE with a 401, I would expect the SIP Proxy to keep enough state to select this same UAS as the target when the originating upstream UAC sends the second INVITE containing authentication credentials.
Instead, what I'm seeing is that the SIP Proxy will proxy the 401 response, receive the ACK from the upstream UAC, and immediately destroy all state pertaining to this dialog. Then when the upstream UAC sends the second INVITE with authentication credentials the SIP Proxy will forward that request in round-robin fashion. If we get lucky then the SIP Proxy will select the same UAS for the second INVITE, but most of the time it will select some other downstream target.
I'm new to SIP and I've been reading RFC 3261 to try and understand what the correct behavior should be, but I'm not seeing an obvious answer.
I think what you are really asking is an understanding of how further requests within a dialog work. For that you need to understand the "Record-Route" / "Route" headers.
It really doesn't mater what the response code is, the next request in the dialog will go directly to the remote URI unless (and there almost always is) a route set provided.
From section 12 of RFC 3261:
The route set is the list of servers that need to be traversed to
send a request to the peer.
From section 16.6 Request Forwarding
4. Record-Route
If this proxy wishes to remain on the path of future requests
in a dialog created by this request (assuming the request
creates a dialog), it MUST insert a Record-Route header field
value into the copy before any existing Record-Route header
field values, even if a Route header field is already present.
From 20.34 Route
The Route header field is used to force routing for a request
through the listed set of proxies. Examples of the use of the
Route header field are in Section 16.12.1.
From 12.1.2 UAC Behavior
The route set MUST be set to the list of URIs in the Record-Route
header field from the response, taken in reverse order and preserving
all URI parameters. If no Record-Route header field is present in
the response, the route set MUST be set to the empty set. This route
set, even if empty, overrides any pre-existing route set for future
requests in this dialog.
From 16.12 Summary of Proxy Route Processing
In the absence of local policy to the contrary, the processing a
proxy performs on a request containing a Route header field can be
summarized in the following steps.
1. The proxy will inspect the Request-URI. If it indicates a
resource owned by this proxy, the proxy will replace it with
the results of running a location service. Otherwise, the
proxy will not change the Request-URI.
2. The proxy will inspect the URI in the topmost Route header
field value. If it indicates this proxy, the proxy removes it
from the Route header field (this route node has been
reached).
3. The proxy will forward the request to the resource indicated
by the URI in the topmost Route header field value or in the
Request-URI if no Route header field is present. The proxy
determines the address, port and transport to use when
forwarding the request by applying the procedures in [4] to
that URI.
See this example for how it works.
So basically the initial request should build up "Route-Set" that is then used to generate the "Route" header in the following request.
So for your problem, it sounds like either the "Route-Set" is not being built up and/or being sent back in the response or the UAC isn't using the remote target and route set to build the Request-URI and Route headers correctly for the next request.
There is also the difference between strict and loose routing which also may be in play here as well. I would assume you would be using lr tho.
Related
I need to get value for X-AnchorMailbox and X-PublicFolderMailbox header for public folder requests. I was using both of those articles first and second to retrieve values for headers but a problem happened during autodiscover process.
To send autodiscover request I use derived endpoint because i write my application in C++ and use only SOAP/POX requests to retrieve any data from EWS. If i understood correctly this kind of endpoints should be derived from user's e-mail address. So if the user has address user#test.onmicrosoft.com one of the endpoints should be https://test.onmicrosoft.com/autodiscover/autodiscover.xml (for POX). But this endpoint doesn`t work at all.
Is there any way to get correct endpoint or other ways to retrieve values for headers?
There are multiple endpoints (https and http redirect). Plus the endpoints from AD and DNS.
Start at Autodiscover for Exchange
In your particular case (redirect to a hosted M365 mailbox), you will most likely end up going through the unsecured (http://autodiscover.YourDomain.demo/autodiscover/autodiscover.xml) redirect (301, 302, 307, 308) to https://outlook.office365.com/autodiscover/autodiscover.xml
You can also see autodiscover steps if you try the connectivity analyzer at
https://testconnectivity.microsoft.com/tests/Ola/input
I have a CloudFront distribution with a Lambda function attached to the viewer request hook. I'm using this to redirect to the canonical domain (eg. www.foo.tld -> foo.tld). I also have the distribution itself set up to redirect HTTP -> HTTPS.
The problem is that this requires clients to potentially have to do 2 requests to get to the correct URL. For example:
http://www.foo.tld/ -> https://www.foo.tld/ (performed by CloudFront)
https://www.foo.tld/ -> https://foo.tld/ (performed by Lambda function attached to viewer request hook)
I would like to have this done in 1 request:
http://www.foo.tld/ -> https://foo.tld/
It looks like I need to add this functionality to the Request Event, but the documentation seems to indicate the protocol is not exposed to the Lambda function in the request event.
My question is:
How do I expose the protocol to the Lambda function attached to the Viewer Request hook?
Alternately, is there a better way to do this?
Side note: redirects that change both the hostname and the scheme may be problematic, more in the future than now, as browsers become less accepting of HTTP behavior without TLS. I am at a loss, at the moment, to cite a source to back this up, but am under the impression that redirecting directly from http://www.example.com to https://example.com should be avoided. Still, if that's what you want...
CloudFront and Lambda#Edge support this, but only in an Origin Request trigger.
If you whitelist the CloudFront-Forwarded-Proto header in the Cache Behavior settings, you can then access that value like this:
const request = event.Records[0].cf.request; // you may already have this
const scheme = request.headers['cloudfront-forwarded-proto'][0].value;
The value of scheme will either be http or https.
I'm a little bit pedantic, so I like a failsafe. This alternative version will always set scheme to https and avoid the exception that will be thrown if for whatever reason the header is not there. This may or may not suite your taste:
const request = event.Records[0].cf.request; // you may already have this
const scheme = (request.headers['cloudfront-forwarded-proto'] || [{ value: 'https' }])[0].value;
The reason this can only be done in an Origin Request trigger is that CloudFront doesn't actually add this header internally until after the Viewer Request trigger has already fired, if there is one.
But note also that you almost certainly want to do this in an Origin Request trigger -- because responses from these triggers can be cached... which should mean faster responses and lowered costs. Whitelisting the header also adds it to the cache key, meaning that CloudFront will automatically cache separate HTTP and HTTPS responses for any given page, and only replay them for identical requests.
See also https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-requirements-limits.html#lambda-cloudfront-star-headers
So I am trying to automate a JMeter script that creates Keycloak users and then signs them in.
First It GETs the login page and stores the code, here is an example request:
GET http://Keycloak.com:8001//auth/realms/REALM/protocol/openid-connect/auth?response_type=code&client_id=CLIENT&scope=openid%20profile%20email&nonce=N5b3a2da23c04a&response_mode=form_post&resource=RESOURCE&state=2SJwtlVZrswlGkw&redirect_uri=REDIRECTURI
However, when I then GET the registration page, the code changes and the tab_id also changes. How can I keep keycloak from generating a new code token with every HTTP request in a thread?
In addition, why is each HTTP request with JMeter acting like a new session instead of the next request in a series?
EDIT:
I am using Regular Expression Extractors in order to track the code and execution variables, in addition to using a HTTP Cookie Manager and HTTP Cache Manager for the thread.
Looking at my POST request, both variables are the same as those from the previous HTTP request, and all of my cookies are being maintained, yet every time I try this automated login, I get a 400 error and the keycloak event log displays an invalid_code error.
Edit:
As requested here is a screenshot of all my sign in requests
Most probably your Regular Expression Extractor is not nested in the HTTP Request you are trying to extract data from.
If its scope is too wide, it applies to all HTTP Requests, so first time it succeeds extracting, but then for the next request that does not contain the token, the extractor runs and overwrites the old value by an empty one.
See scoping rules in JMeter:
https://jmeter.apache.org/usermanual/test_plan.html#scoping_rules
You need to maintain the corelation between hits. Please go through below blog
https://www.blazemeter.com/blog/how-to-handle-correlation-in-jmeter
According to keycloak you must use https if you are using keycloak.com
Keycloak can run out of the box without SSL so long as you stick to private IP addresses like localhost, 127.0.0.1, 10.0.x.x, 192.168.x.x, and 172..16.x.x. If you don’t have SSL/HTTPS configured on the server or you try to access Keycloak over HTTP from a non-private IP adress you will get an error.
So you have 3 options: use private IP address, use a reverse proxy or load balancer to handle HTTPS or enable HTTPS for the Keycloak server.
I am working on a software that use http post to do some things. The http post work perfect everywhere but in windows server 2012 it need specific header order. I am attaching fiddler screenshots. In the screenshots you can see that if i change header order it stop working.
Specific order works:
Changing host to other line not working:
Header order is not important for headers of different names (the order of headers with the same name does matter):
RFC 2616 Section 4.2 Message Headers
The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header fields.
RFC 7230 Section 3.2.2 Field Order:
The order in which header fields with differing field names are received is not significant. However, it is good practice to send header fields that contain control data first, such as Host on requests and Date on responses, so that implementations can decide when not to handle a message as early as possible. A server MUST NOT apply a request to the target resource until the entire request header section is received, since later header fields might include conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing.
If the HTTP server does not work correctly when the Host header is not in a desired order, then it is in violation of the HTTP specification, as the header can appear in any order and the server must be prepared to handle that.
I'm loading my script on a domain and sending some data with POST and the use of Ext.Ajax.request() to that same domain.
Somehow the dev-tools show me, that there is a failed OPTIONS request.
Request URL : myurl-internal.com:8090/some/rest/api.php
Request Headers
Access-Control-Request-Headers : origin, x-requested-with, content-type
Access-Control-Request-Method : POST
Origin : http://myurl-internal.com:8090
It's both HTTP and not HTTPS. Same port, same host ... I don't know why it's doing this.
The server can't handle such stuff and so the request fails and the whole system stops working.
It's not really specific to Ext JS -- see these related threads across other frameworks. It's the server properly enforcing the CORS standard:
for HTTP request methods that can cause side-effects on user data (in
particular, for HTTP methods other than GET, or for POST usage with
certain MIME types), the specification mandates that browsers
“preflight” the request, soliciting supported methods from the server
with an HTTP OPTIONS request header, and then, upon “approval” from
the server, sending the actual request with the actual HTTP request
method.
If you're going to use CORS, you need to be able to either properly handle or ignore these requests on the server. Ext JS itself doesn't care about the OPTIONS requests -- you'll receive the responses as expected, but unless you do something with them they'll just be ignored (assuming the server actually allows whatever you're trying to do).
If you are NOT intending to use CORS (which sounds like you aren't purposefully going cross-domain) then you need to figure out why the server thinks the originating domain is different (I'm not sure about that). You could also bypass CORS altogether by using JsonP (via Ext's JsonP proxy).
Use relative url instead of absolute, then you will get expected result.
use before request
Ext.Ajax.useDefaultXhrHeader = false