Hi, I would like to know if exist some REST API to detect if a platform has installed Diego. Reading API from Cloud Controller, I didn't recognize some method to identify Diego in CF

Hi Charles, You said the clue!!! Yesterday, I updated the development and I could deploy on PWS. From environments without Diego, the way to run a Node development is: var localPort =

Oh right I misread it I thought it was avoid application to connect to certain IP..... wrote:

Gwenn, If I'm not wrong Application sec rules are for restricting outbound traffic from application side , no? Ronak

What about https://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html ? carlo.ferraris(a)rakuten.com> wrote:

Is there any provision for restricting the source IPs that are allowed to access a certain application (or route)? Or the only way to do this is to place a reverse proxy in front of the gorouter? In

Matt, that's awesome, thanks! Mind trying this? require 'uri' require 'net/http' require 'logger' SYSTEM_DOMAIN = '--CHANGE-ME--' u = URI.parse('http://uaa.' + SYSTEM_DOMAIN + '/login') h =

once the tcp routing work is done with the haproxy approach, you should be able to try mutual ssl using a IP/port. you should be able to test tcp routing with lattice now. however web traffic using a

Does any one have any experience using SSL mutual authentication for an app running on CF? Thanks! Anthony

Amit, Here's a run with the problem manifesting: ... 00248 [200]: ruby 26ms | curl 33ms | nslookup 21ms 00249 [200]: ruby 20ms | curl 32ms | nslookup 14ms 00250 [200]: ruby 18ms | curl 30ms |

best way around it , same as in the story. set the time zone of the UAA can to match DB vm

If you're using the common bosh lite IP of 10.244.0.34, you can also use the more-reliable *.bosh-lite.com

Yes, xip.io is flaky. I would recommend setting up real DNS if you want to avoid the 2% failure rate if you want a longer term, reliable solution. wrote:

Hi, Currently we see IO errors when trying to contact xip.io - this happens around 2% of the times. To apply a temporary fix - I updated the /etc/hosts of the ha_proxy VM to map the - IP to the

Hey Matt, Dieu's suggestion will fix your problem (you'll have to make the change on all CC's), although it'll get undone on each redeploy. We do want to find the root cause, but have not been able

Thanks for authoritive answer. My application is a Java (Spring Framework) one hence the solution with Spring Security is just fine for me.

Yep, this is not supported. Our recommendation is to do consolidation on the LDAP side. -Sree

It appears my issue was caused by this uaa issue: https://github.com/cloudfoundry/uaa/issues/223 Now to figure out the best way to work around it. Thanks for your help Matt. Mike

We have seen this with some node apps. Does your app or buildpack reference either of the following env variables VCAP_APP_HOST and

If your `access_token` value is 1. a client_credentials grant - the `oldPassword` field is not evaluated and can be omitted OR 2. it's a user token, with the scope of `uaa.admin` and the admin is