I have a bit of an issue that I can't seem to wrap my head around. The app/site is secured complete with a SSL Certificate, but we need to send an $http request with angular to a non-secured api end-point. The service does not offer a https solution and everytime we try sending the request, our server blocks it because it is not secured. Is there anyway to get around this? A way to "whitelist" the domain name or something?
Information: Server is running Nginx and the request is being made via $http angularjs.
Related
I'm currently trying to configure a route we can call it sub.domain.com/route and on domain.com I have a angular app that sends a post to that end point.
What I'm trying to figure out is do I have to add in CORS to sub.domain.com/route to only allow post requests from domain.com? Or do I have to create a tokening system on domain.comto prevent someone from being able to send curl requests and use that route or to use that route on their website/app without my consent?
I'm trying to limit people who can access that route to only people who are physically on domain.com using my application and clicking the button that sends the post request.
You will need to use some other form of authentication (e.g., tokening, password, etc...) as CORS will only affect whether or not resources such as scripts, served to a user's browser from one domain will be able to interact with services hosted on another. This will do nothing to help against CURL requests, proxies, etc...
I'm setting up a simple authentication service for my angular website using Spring for my backend and I have a following problem.
When I send a cross domain get request with credentials (REST controller on backend), I get authorized by Spring Security, I get a JSESSION cookie and all is fine. What's not fine is that the cookie isn't saved and I can't access it in any way I could think of to save it manually.
Am I missing something here? If you need additional information, I'd be glad to provide it.
#Edit
I have Set-Cookie header in my response:
(...)
Server
WildFly/8
Set-Cookie
JSESSIONID=CODE; path=/PATH
(...)
I got a problem with apigility and https.
To enable https communication between AngularJs frontend and Apigility backend, I used this tutorial:
http://robsnotebook.com/xampp-ssl-encrypt-passwords. Almost everything works fine, but REST webservices doesn't respond via https.
When, using Advanced REST Client, I'm sending request e.g.
https://localhost:8888/status
NO RESPONSE appears.
Does anyone know where might be the problem?
For defiantly it is server fault. My apigility instances are working perfectly normal on production server with SSL. Could you give some more information.
Can you open your apiglity admin panel by browser? Is it working?
Is there any error in response headers or some other clue? Are you sending "Accept" header?
What is your apigility and zf2 versions?
We are having a web application architecture where our application EAR is deployed in appServer configured with non-ssl Http Port Listener. Every request is routing via F5 Load Balancer-> Web Server-> App Server.
In Load Balancer, we have set an iRule where every Http Request is forwarded to Https set on port 443 and our application is working fine. Now we are trying to implement a SSO using OpenSSO federation solution and SAML Technology. we have deployed the opensso with the non-ssl http listener configuration in our app server.
now when we try to access the opensso using the url xhttp://domain_name/opensso(dummy protocol), it is redirected as per iRule set on the Load Balancer as xhttps://domain_name/opensso. But in the appearing configuration page of opensso, the server URL is populated as xhttp://domain_name only instead of xhttps://domain_name. Likewise, the same approach is followed to populate all the URL properties throughout the opensso configuration. So when I tried to generate the metadata using ssoadm GUI, In the form action attribute the url is formed as 'http' and the request method is passed as 'POST' only as per Opensso convention. But when it is redirected to 'https' as per the Load Balancer Rule the Request method is passed as 'GET' instead of post and the opensso validation fails and throwing the error as 'HTTP Post Protocol is required.
So the issue here is, By default the opensso URL properties should be populated with "https" instead of "http". I would like to know what is the wrong configuration done here. how we could resolve this issue? Thanks.
I think that you will find that the answer actually lies within your application server, not the application itself. You need to indicate to the servlet that it is being proxied, and that it is responsible for creating URLs with the HTTPS scheme, not HTTP.
If you're using Tomcat or a derivative, you can modify the server.xml to include the following:
proxyPort="443"
proxyName="www.domain_name.com"
scheme="https"
secure="true"
You can configure the load balancer to redirect to https with a 307 http status code which informs the client to use the original request method. If POST was the original request method then following the redirect the client will continue to use POST instead of a GET.
HTTP::respond 307 Location "https://[HTTP::host][HTTP::uri]"
I'm using nginx on the remote server, and with no support for the OPTIONS method I've been terribly stuck. Both the server and angular refuse to talk to each other.
I just want to make a simple $http.post() request. Is there a way to configure the service to ONLY send the POST request, and not do any preflighting with OPTIONS?
This is not something AngularJS does, but something your browser does according to the Cross-Origin Resource Sharing standard. See also this answer on a related issue.
However, if you make it so that the AngularJS application is served from the same domain as your resource (different subdomains will affect cross-origin), then the browser will not send the OPTIONS request as the resource is no longer from a cross-origin server.
Example:
www.example.com requests resource on api.example.com will trigger OPTIONS request
www.example.com requests resource from www.example.com/api will not trigger OPTIONS request
If CORS is Unavoidable
You could change the header of the request to text/plain and then parse your response manually acording to answers in this link below
How to skip the OPTIONS preflight request in AngularJS