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.
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
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'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.
I am currently trying to setup AWS Api Gateway, to proxy to another api, that has fully functional methods, response content, status codes etc. This is fairly simple to setup, but I have noticed that the Api Gateway always returns 200 OK no matter what the origin api responds with.
Fx. if there was a bad request (in the origin api) which results in a error message in JSON and a 400 Bad Request, the Api Gateway will respond with a the exact same error message, but a status code of 200 OK
If I remove all settings from the Message Response in the API Gateway web-interface, I get an internal error in the API Gateway. Can it be true that I have to map all the different status codes from the origin api manually in the Api Gateway?
I would prefer if it was possible to just let the status code (as well as the response, which currently works great) pass through, and not have the Api Gateway touch it in any way.
Proxy integration can be used to achieve this. In this case, it is HTTP Proxy. Lambda Proxy integration can also be used but will need some code logic in lambda. API GW will then return the result as-is.
You are correct that currently when using API Gateway you are required to map all response codes in your integration responses. We have heard this "pass through" request from other customers and we may consider including this in future updates to the service.