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
Related
I'm building an MVC web app that uses the openID Connect hybrid flow to authenticate with Identity Server 3. The MVC web app contains jQuery scripts to get async JSON data from een ApiController. That ApiController is part of the same MVC web app.
I don't want that everyone is able to access the data from the API, so I want to secure the API as well. I added an [authorize] attribute to the ApiController. When requesting the API with a JQuery ajax request I get the following error message:
XMLHttpRequest cannot load
https://localhost:44371/identity/connect/authorize?....etc.
Response to preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:13079' is therefore not allowed
access. The response had HTTP status code 405.
But, when I do a request to the API method directly in browser, I will be correct redirected to the Login page of Identity Server..
So, what's exactly the problem here? I read something about that requesting the /authorize endpoint is not allowed via 'back-channel', but I don't understand what's the difference between 'front-channel' and 'back-channel'. Is it possible that I mixed up the wrong OAuth flows? Is the Hybrid flow not the correct one maybe?
I also find out that the API is often a seperate app, but is it always neccessary / best-practice to build a seperate API app that for example requires a bearer token?
Please point me in the right direction about this.
The authorize method on your identity server does not allow ajax calls. Even specifying CORS headers is not going to help you in this particular case. Perhaps you could return a forbidden response instead of a redirect and manually redirect the client to the desired location via window.location
You need to allow your IdentityServer to be accessed from other domains, this is done by allowing "Cross Origin Resource Sharing" or CORS for short. In IdentityServer the simplest way to allow this is in your Client configuration for your Javascript Client, see this from the IdentityServer docs on CORS:
One approach to configuing CORS is to use the AllowedCorsOrigins collection on the client configuration. Simply add the origin of the client to the collection and the default configuration in IdentityServer will consult these values to allow cross-origin calls from the origins.
The error you're seeing is the browser telling you that when it asked IdentityServer if it allows requests from your Javscript client, it returned a response basically saying no, because the origin (http://localhost:13079) was not specified in the "Access-Control-Allow-Origin" response header. In fact that header wasn't in the response at all meaning CORS is not enabled.
If you follow the quickstart for adding a JavaScript client from the docs here all the necessary code is detailed there that you need for the Client config and to setup IdentityServer to allow CORS.
I am trying to access NIFI rest api of another server from my machine using ajax like below,
url:"https://serverip:port/nifi-api/",
{Authorization : 'Bearer ' + 'access token here'}
Getting Response to preflight request doesn't pass access control
check: No 'Access-Control-Allow-Origin' header is present on the
requested resource error.
Apache NiFi's API is designed to be invoked by a variety of clients, but in this case I think you are encountering a security precaution put in place by CORS (Cross-Origin Resource Sharing).
If a piece of code on server A (your non-NiFi machine) makes an AJAX request to a different origin (your NiFi instance), and the HTTP method is not GET (and some other minor restrictions), server A will first send a "preflight" request, which is HTTP OPTIONS, to the remote instance to determine what requests are valid. A server can reply to this with the header Access-Control-Allow-Origin: *, which is a wildcard value denoting it accepts requests from any origin. However, if you want to send credentials along with the request, the originating hostname must be explicitly listed in the response (Access-Control-Allow-Origin: https://serverA.com).
Because NiFi uses an embedded Jetty server to host the API, you may have to explicitly add a CrossOriginFilter as described here.
Is it possible to restrict requests on Parse.com to a certain domain (i.e. the hosting domain)?
The request in question is a cloud function.
Thanks!
You can get the ip address as part of the request object. You can apply a filter in cloud code to allow request from certain ip otherwise send 401 Unauthorized Request http code.
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.
I'm starting with an address for an Exchange 2007 server:
user#domain.exchangeserver.org
And I attempted to send an autodiscover request, as documented at MSDN.
I attempted to use the generic autodiscover address documented at the TechNet White Paper.
So, using curl on PHP, I sent the following request:
<Autodiscover
xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
<Request>
<EMailAddress>user#domain.exchangeserver.org</EMailAddress>
<AcceptableResponseSchema>
http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a
</AcceptableResponseSchema>
</Request>
</Autodiscover>
to the following URL:
https://domain.exchangeserver.org/autodiscover/autodiscover.xml
But got no response, just an eventual timeout.
I also tried:
https://autodiscover.domain.exchangeserver.org/autodiscover/autodiscover.xml
With the same result.
Now, since my larger goal is to use Autodiscover with Exchange Web Services, and since all of the EWS URLs typically use the same sub-domain as the Outlook Web Access address, I thought I'd see if the same were true for autodiscovery URLS. Since the OWA URL is:
OWA: https://wmail.domain.exchangeserver.org
I tried:
https://wmail.domain.exchangeserver.org/autodiscover/autodiscover.xml
And sure enough, I got back the expected response.
However, I only knew the OWA sub-domain because it's the server I have access to and that I'm using to test everything. I would not know it for sure or be able to guess it if this were a live app and the user was entering in their own Exchange email.
I know that the autodiscover settings must be available without knowing the OWA URL, because I can enter:
user#domain.exchangeserver.org
into Apple Mail on Snow Leopard and it finds everything without trouble.
So the question is...
Should https://domain.exchangeserver.org/autodiscover/autodiscover.xml have worked, and I just missed a step when trying to connect to it? Or,
Is there some trick (maybe involving pinging the email address?) that Apple Mail and other clients use to resolve the address to the OWA subdomain before sending the autodiscover request?
Thanks to anyone who knows or can take a wild guess.
After a bit more banging my head against the Google, I found the following very helpful article on MSDN:
http://msdn.microsoft.com/en-us/library/ee332364.aspx
Specifically the section "Calling Autodiscover"
I'm still trying to figure out how to do a Active Directory Service Connection Point search via LDAP, but step 4, for my server at least, worked like a charm:
The application sends an unauthenticated GET request to http://autodiscover.contoso.com/autodiscover/autodiscover.xml. (Note that this is a non-SSL endpoint).
If the GET request returns a 302 redirect response, it gets the
redirection URL from the Location HTTP
header, and validates it as described
in the section “Validating a
Potentially Unsafe Redirection URL”
later in this article.
Sure enough, a request sent to:
http://domain.exchangeserver.org/autodiscover/autodiscover.xml
sent back a 302 redirect URL:
https://wmail.domain.exchangeserver.org/autodiscover/autodiscover.xml
But this article gives a series of steps, so anyone wanting to implement autodiscover for an Exchange client has 5 things to try before giving up.