I have an IIS application server in China, but one of our applications is access Salesforce soap api and it is too slow now. I want make this application access network via http proxy. How can I achieve that?
You would use the WebProxy class from .net
https://msdn.microsoft.com/en-us/library/system.net.webproxy(v=vs.110).aspx
WebProxy proxyObject = new WebProxy("http://proxyserver:80/",true);
WebRequest req = WebRequest.Create("http://www.contoso.com");
req.Proxy = proxyObject;
Related
I am running IIS and Node in parallel on a Windows Server. Is it possible to allow IIS intercept HTTPS requests, authentic them using Windows Authentication (Negotiate/NTLM), then proxy the requirements onto Node as HTTP requests with username and security groups in the header for Node to process?
As far as I know, it is possible to use windows authentication before proxy request. Windows authentication is to authenticate people through the local Windows network. There is no proxy server or even a proxy server. Protocol does not authenticate HTTP sessions, but authenticates the underlying TCP connection.
IIS can also proxy the request to Node, as long as the request is rewritten using ARR and URL rewrite.
However, IIS itself cannot obtain the user name and security group information, and requires the help of ASP.NET applications.
I have been trying to configure access to an on-premise Web API from a native application using this walkthrough: How to enable native client applications to interact with proxy applications
According to the walkthrough,
"To support native client applications, Application Proxy accepts Azure AD-issued tokens that are sent in the header."
However, regardless of the tokens that I send in the request header, the proxy always responds with HTTP 302 and redirects me to the sign in page.
Has anyone been able to pass Azure app proxy pre-authentication using a token?
I have a web app configured in my Azure AD.
On a machine, i have installed a connector and configured an application proxy with that connector.
I am now trying to connect from an Android mobile application to the web app through the application proxy.
If I use a WebView inside my app, I can load the User access URL, enter my credentials and I receive a cookie for use by following connections.
I need to be able to use other HTTP clients that do not have the possibility to show UI.
I was wondering if it was possible to somehow request access and refresh tokens, and add those to future requests. or if possible convert them to a cookie in some manner and add that in a header.
Your client app can simply use MSAL (or ADAL, or another OpenID Connect client library) to sign the user in and an access token for the App Proxy app. Then you can include that token in the Authorization header in requests to the endpoint from App Proxy. App Proxy will recognize it, validate it, and (if everything checks out) proxy the call down to the App Proxy connector, where the rest of the process happens as normal.
Here are the relevant docs: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-native-client-application
I am currently developing an API that will be launched into production in a matter of weeks. I am relatively new to REST, started reading about CORS - and realized that it could impact me.
What conditions will a REST service not be accessible to a client? I have been using sample html/js on the same server, and through Postman - a google chrome addon - to access my API. I have had no issues so far.
When the API goes live, it will be hosted at 'api.myserver.com'. Requests, at the beginning, will come from 'app.myOTHERserver.com'. Will these requests be denied if I do not use a CORS-friendly approach like JSONP or special 'access-control' headers that permit my domain?
What about accessing rest APIs from other non-browser clients? Such as a C# application? Are these requests permitted by default?
Assuming I do need to add 'access-control' headers server-side, to permit the scenario described above when my API goes live, is it better (performance-wise) to let your web server (NGINX in my case) handle the headers, or should I add them through PHP or NodeJS?
This is more about the same-origin policy applied by web browsers than it is about RESTful APIs in general.
If your API is intended to be used by web applications deployed on a different origin host/port than the API, then you have these options:
Respond with appropriate headers that allow for techniques like CORS to work.
Have the web server which serves up your web content (in your example, app.myOTHERserver.com) handle your REST API requests too by proxifying your API requests from the web server through to the API server. For example, you could have your API exposed on your web server under the URL /api, and then it's just a matter of setting up a web proxy configuration that forwards requests under that URL to your API server.
Use JSONP or other techniques.
If your API is going to be used by non-web applications, you have nothing to worry about. This is only a restriction applied by browsers when running JavaScript code to make sure that the user hasn't inadvertently clicked on a phishing link with some hackery in it that tries to send their PayPal password to Pyongyang.
When the API goes live, it will be hosted at 'api.myserver.com'.
Requests, at the beginning, will come from 'app.myOTHERserver.com'.
Will these requests be denied if I do not use a CORS-friendly approach
like JSONP or special 'access-control' headers that permit my domain?
You can specify what clients can access your web service to an extend. Assuming you're using Express: How to allow CORS?
I'm trying to add Active Directory single-sign-on support to an existing SOAP server. Since it is written in C++ using third party transport components, adding AD SSO doesn't appear to be easy.
Therefore I am thinking to require IIS as a trusted reverse-proxy and let it do the Active Directory authentication for the SOAP server. That is, offload all authentication duties to IIS, and just rely on the X-Remote-User HTTP header at the SOAP server. Since the SOAP client is using the WinInet API, all of the authentication is done for us, and this give the SOAP server single-sign-on for free.
client
-> IIS (Active Directory authentication)
-> SOAP server (with X-Remote-User: USERID header)
This appears that it should be a fairly common problem space, however although I have found a few IIS proxy programs, I thought that this may be something built into IIS.
Is this sort of functionality built into IIS or do I need to build a proxy myself?
Is there a better option than requiring IIS?