Is refresh token always returned, for all the grant types ? It seems to be the case for authorization_code grant type but I don't think it is returned for client credentials

Hi all, We've recently announced CF Summit events for both Berlin and Shanghai, and we'd love your participation! Berlin will be on November 2nd and 3rd, 2015 > http://berlin2015.cfsummit.com/ The

Hi Mike Thanks for addressing my questions gain. I agree that it's important to make both the rootfs and the buildpacks backward-compatible with each other. People often use master branch of the

Hi Jack, Thanks for asking these questions. Not knowing what specific changes you're referring to, I'll try to address some different aspects of the topic. First, just to set expectations, `lucid64`

That did the trick, thanks Filip. Using Basic auth, cf as client id and an empty password is the solution Keagan

I notice that there are a few changes going into the rootfs [1]. Are there corresponding changes in the buildpack which would make them unable to work properly in older levels of the rootfs (both

I set up the open source CF and got the metrics streamed out of the firehose. I also read document about Pivotal Ops Metrics in

cf client is fine. put empty string as a password Filip wrote:

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:

Your authorization header should be Basic (meaning, you need the client id and secret to retrieve the refresh token)

Simple test that does what you need https://github.com/cloudfoundry/uaa/blob/develop/uaa/src/test/java/org/cloudfoundry/identity/uaa/integration/RefreshTokenSupportIntegrationTests.java#L147-L150 we

Correct, the datadog-firehose-nozzle has its own custom client which makes REST calls to the datadog API. It doesn't use the datadog statsd agent. A similar approach should work for

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

This is an issue with authorization. You have to use a user with the correct scope. Specifically, use a client with a scope/authority of 'uaa.admin' The easiest way is to use the 'app' client to

Hi, I am searching for a way to get a refresh token and I haven't been able to do so. I did not find any info on the way to refresh a token. I was looking for some docs externally and found some

Hi Eric (a different Marco here), I noticed that delivery status for cf-bosh had been set to 'disabled' last week, and re-enabled it. It's the only of the three that I have set to 'Mime Digests'

i found all new apps cannot be created now. caused by this issue. Any clue for it?

*but I will see about reproducing this today Requested documentation in UI as a followup to https://gitlab.com/mailman/postorius/issues/30 as well as posting another bug about unset values and

Hi James / cf-dev There are tests, but the corner case fell through the cracks - bug[1] and additional test request[2] added. For everyone else, most of the discussion appeared to happen in

Hi Marco, Just to confirm, did you leave it enabled in "mime digest" mode for longer than a day so that there was list traffic to bundle and digest for you? I don't see any errors in the error log