I agree with your root argument that the port check doesn't really address application health and it's easy to push a non-working app and have the healthcheck still pass. My argument is that is exactl

Also just occurred to me - what if the page returns a 302, 401, or 404? I'm guessing it would make the healthcheck fail because it wouldn't be a match against Result.IsSuccessStatusCode. :-( Aaron --

I shut off the healthcheck via the CLI and then started a separate process calling healthcheck.exe on my test servers after setting the port environment variable: Looking at the data from running all

The app is just a simple one page test app we've been using since we landed Iron Foundry, here is the content in our default.aspx: <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.asp

We've started testing Windows apps on Diego in our lab and everything appears to be working correctly except for occasional crashes of the .NET apps. The frequency is very random - some times I can go

So we're just using the cf client which doesn't have a secret defined, is that why we need to use the admin client? -- View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-CF-UAA-Ref

Not sure I understand that. When you get a token you also automatically get a refresh token - are you saying the refresh token given isn't valid and we have to generate a new refresh token as an admin

I can certainly confirm that for Intel this feature would be required for us to use ssh/scp access at all, and maybe not even then. We've been selling Cloud Foundry to our security folks as a huge imp

You can use the allow_host_access property in your manifest to enable the access. It simply suppresses the iptables rule you mention that rejects the traffic. https://github.com/cloudfoundry/cf-releas

In our case we use email address as the username via LDAP as well (UPN actually, but same thing) so it would be the same. Is there a timeline for the ECP profile support? Aaron Sent: Wednesday, May 13

That’s the main concern we have as well – we currently need LDAP for the CLI since SAML doesn’t work in that case, but we’d like SAML for web-based interactions (SSO in a portal, etc.). But at present

Would the same user logging in via SAML and LDAP result in two different UAA user objects with different sources, so that the user would have two different sets of orgs/spaces/apps? Aaron -- View this

I've created Nabble archives of the CF lists here: http://cf-bosh.70367.x6.nabble.com/ http://cf-dev.70369.x6.nabble.com/ http://cf-lattice.70370.x6.nabble.com/ The archives are searchable and allow w