I'm working with a sysadmin that uses a Juniper solution that behaves as a proxy. I have no idea what it is, but here's a picture of the web interface: http://imagebin.ca/v/1UKN1jGYPUWd
Through that proxy, I'm trying to use Sharepoint's REST API, unfortunately there are some headers (such as X-RequestDigest) that Juniper's proxy doesn't forward to Sharepoint.
Basically, I need the equivalent of nginx's proxy_pass_request_headers for Junipers' applications.
The sysadmin doesn't seem to know what HTTP header forwarding is, or how to configure it. Can anyone identify the solution he's using from the picture ? Does anyone know where to find documentation about this ?
Further to my comment added above, there appears to be no way to implicitly pass variables around. You can tell the current IVEOS images that the Web URL you're linking to is a Sharepoint Site, and it'll do "clever" things with the URL, but I'm not exactly sure what you want it to do, and whether they'll handle it.
Here are the screen shots for the "Sharepoint" configuration panels on the Web Resources page. As I'm not a Sharepoint Admin, I can't tell you whether these are useful to you or not.
I hope it helps!
You may be looking for the Web Resource custom header policy
https://www.juniper.net/documentation/en_US/sa8.0/topics/task/operational/secure-access-web-rewrite-custom-header-policy.html
Edit: The first resource became a dead link. New link: https://www.juniper.net/techpubs/en_US/nsm2012.2/topics/task/configuration/remote-management-secure-web-resource-policy-configuring-nsm.html
Fur custom headers (to send some user information) we've used the "Web Rewriting Resource Policy"
SSO Cookies/Headers > General tab -> Headers and Values
to pass custom user data (user name, role, client certificate).
I assume you have the backend application (sharepoint) configured as the a PTP (PassthroughProxy) we bresource. I am pretty confident that only standard HTTP headers are passed to the backend by default :(
To pass all custom headers I found following book (Juniper(r) Networks Secure Access SSL VPN Configuration Guide): https://books.google.be/books?id=5OYf6u5vzFsC&pg=PA369&lpg=PA369&dq=Juniper+pass+custom+headers&source=bl&ots=s5oF5NEKjP&sig=8091EV2Pyw6pIFQifMOIR2pLpLk&hl=de&sa=X&ved=0ahUKEwiFwpf6m_DOAhWFWRQKHXoRD0EQ6AEIPDAE
where it says
Passing custom headers can be enabled by:
Users > Resource Polities > Web > Custom Headers
This option may not be visible on the admin interface by default, it needs to be enabled:
Users > Resource Policy > Web > Web ACL and there's a "Customize" button
Related
I want to call REST-services from my Angular-app. However, these REST-services are hosted on WLP and are part of a WAR-file developed by some company a while ago, ie. we have no source code.
I can call GET-methods without any issues from Postman, I just need to set authentication and accept headers. However, calling these GET-methods from Angular via web browsers will trigger preflight request (OPTIONS) without Authentication header prop. Seems to me that OPTIONS requests are triggered by the browsers and Angular cannot set headers for them. I confirmed OPTIONS requests need authentication by running requests via Postman with and without auth header prop.
Similar problems were discussed in other posts on stackoverflow but in such cases people had control over their server side code and could alter it to avoid authentication headers for OPTIONS request. Clearly in my case, I cannot do it.
My question is if there is a possibility to configure WLP to not ask for authentication header prop in case of OPTIONS-requests (seems to be configurable for Apache web servers and Tomcat)?
Kind regards
A.H.
Even without source, you should be able to edit web.xml and modify the security-constraints to punch a hole for OPTIONS.
I have been trying to get this resolved, without any success.
I have a webapp residing on my domain, say www.myDomain.com. I need to call a service which is present on another domain, say www.anotherDomain.com/service.do?
I'm using SproutCore's SC.Request.getUrl(www.anotherDomain.com/service.do?) to call that service.
I get an error that says, Origin www.myDomain.com is not allowed by access-control-allow-origin.
When I was in dev stages, and using sc-server, the issue was resolved using proxies. Now that I have deployed the app to an actual server, I replaced all the lines where I had set up the proxy with the actual domain name. I have started getting that error again.
The problem is that I CANNOT MAKE ANY CHANGES to the server on the other domain. All the posts that I have come across state that the other server on the other domain ought to provide access-control-allow-origin header and that it ought to support the OPTIONS verb.
My question is, is it possible for me to connect to that service using SproutCore's SC.Request.getUrl() method?
Additionally, the other posts that I have read mentioned that a simple GET request ought not to be preflighted. Why then are my requests going as OPTION instead of GET?
Thanks a ton in advance! :D
This is not a Sproutcore issue; it's a javascript Same Origin Policy issue.
If you can't modify the production server, you have no option but to develop your own proxy server, and have your proxy hit the real service.
This is effectively replacing sc-server in your production environment.
All this server would do is take the incoming request and pass it along to www.anotherDomain.com/?service.do.
You would need to make sure you passed all parameters, cookies, headers, the http verb, etc....
This is far from ideal, because now errors can occur in more places. Did the real service fail? Did the proxy fail? etc.
If you could modify the other domain, you could
1) deploy your SC app there.
2) put in the CORS headers so you could make cross domain requests
If I want a client to always use a HTTPs connection, do I only need to include the headers in the code of the application or do I also need to make a change on the server? Also how is this different to simply redirecting a user to a HTTPs page make every single time they attempt to use HTTP?
If you just have HTTP -> HTTPS redirects a client might still try to post sensitive data to you (or GET a URL that has sensitive data in it) - this would leave it exposed publicly. If it knew your site was HSTS then it would not even try to hit it via HTTP and so that exposure is eliminated. It's a pretty small win IMO - the bigger risks are the vast # of root CAs that everyone trusts blindly thanks to policies at Microsoft, Mozilla, Opera, and Google.
What are potential solutions to a redirection problem that occurs when trying to make AJAX calls to a CAS-protected, SSL-encrypted resource located on a server different from the CAS server?
The CAS server is used for authentication and behaves as designed. This issue appears to be ajax-specific.
There is a similar question here, but we cannot use the same domain/server/port for the CAS server and the backend resource.
The JASIG CAS mailing lists mentions using JSESSIONID.
Another possible approach is to modify the CAS Filter to change the expired-ticket default behavior to something more robust.
What design pattern would you use to overcome this issue?
I have 2 suggestions:
can you set up a proxy script on the same domain as the one that holds the JS code? That way the proxy script would query the CAS and return desired results
can you enable JSONP? this type of request is not limited by the security policy (but then anyone could use the service)
I never heard about CAS, but in general: Javascript has some restriction called “same origin policy”. A visible ressource is not automatically visible to Javascript, too. Did you try to access the ressource using a reverse proxy to make it available within the same domain? You could also consider to point your domain onto a separate web server and include both servers as reverse proxies (for Tomacat, JKmounts are to prefer) here.
Is there any way to tell your localhost that it can do cross domain ajax calls?
I need this for my testing.
If it is a browser specific issue i am using google chrome.
Cheers.
It's very possible. Let's start with a dev browser.
Step 1: Download Chromium
Windows -- http://www.chromium.org/getting-involved/download-chromium
Mac -- http://www.macupdate.com/app/mac/36244/chromium/
There should be a build ready to go, but these locations change over time. So if these end up with 404's do a Google search for Windows Chromium Download and you'll find it.
Step 2: Then run the executable with this flag after it. --disable-web-security
Windows -- Create a shortcut to the executable and tag this in the Properties. Or run from [CMD].
Mac -- Open up a terminal and run this straight from there with the flag.
And, you should be good to go. I also setup a quick Apache service and run through a 127.0.0.1 configured domain, but localhost should be just fine. Here's proof.
I hope this helps you!
No, it's absolutely not possible. If it could be disabled by the user then it would be the main target for anyone with nefarious or dubious intent, and as prone as any other software to exploitation. It's difficult enough making secure software, without painting on even more attractive targets.
The only way to implement cross-domain Ajax is to route requests via a server-side script.
It's worth mentioning that there is, perhaps, a glimmer of hope for you: in the form of cross-window messaging with HTML 5 postMessage
It's probably worth your having a read of some related (though I'm not sure they're duplicate) questions:
Why the cross-domain Ajax is a security concern?
Firefox Cross Domain Request
Edited in response to comment:
So you mean have a script that takes the params, adds them to the request, sends it out, and then echos out the response object?
Essentially yes. In picture format:
client |--------------> | server side |-----------------------> | remote domain
browser | <----ajax------| script | <------------------------|--/
Edited to add that this is now sort of possible, using Cross-Origin Resource Sharing (CORS); in which a script from one domain sends an Origin HTTP header stating the URL of the page, and the server can respond (if configured to do so) with either an error (if CORS is disabled, or unsupported) or with any requested data.
References:
CORS compatibility.
Cross-Origin Resource Sharing, at the W3.org.
Enable Cross-Origin Resource Sharing.