Date   

Re: v3 cc api style guide feedback requested

Guillaume Berche
 

Thanks for sharing this great spec.

Not sure if you're preferring feedback other the mailing list of GH issue.
Let me know.

General feedback:

+1 for a formal schema for the v3 api as to ease automatic client
generations (api explorer, java sdk, go sdk...) (e.g. swagger format)
Automated tests on the formal schema may also help checking the style guide
is respected. https://www.pivotaltracker.com/story/show/99237980 seems to
only consider documentation benefits so far and not yet client generation
benefits (e.g. https://github.com/swagger-api/swagger-codegen
https://github.com/swagger-api/swagger-codegen/issues/325 )

Would be nice to clarify support for non ascii characters in query params,
such as support for IRI
https://en.wikipedia.org/wiki/Internationalized_resource_identifier as to
avoid mojibake bugs such as the one presumed in
https://github.com/cloudfoundry/cli/issues/560

Would be nice to consider supporting gzip encoding for the json payload
responses as to speed up responses over internet connections
('Accept-Encoding' header)

It general it may make sense to clarify supported HTTP headers (+1 for
etag/if-modified-since support suggested at
https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/2 ).

https://github.com/cloudfoundry/cc-api-v3-style-guide#pagination
*"order_by: a field on the resource to order the collection by; each
collection may choose a subset of fields that it can be sorted by "*

Would be nice to illustrate/precise if multiple sort order can be
supported, e.g. order_by=-state,-created

https://github.com/cloudfoundry/cc-api-v3-style-guide#query-parameters
Precise character escaping on query param values e.g. containing comma:
filtering on name="a,b"

https://github.com/cloudfoundry/cc-api-v3-style-guide#pagination-of-related-resources

GET /v3/apps/:guid?include=space,organization

with pluralized resource name should be GET /v3/apps/:guid?include=space*s*
,organization*s*

https://github.com/cloudfoundry/cc-api-v3-style-guide#pagination-of-related-resources
would be nice to include an example of a pagination request on a related
resource inclusion request (e.g,

/v2/spaces/ab09cd29-9420-f021-g20d-123431420768?include=apps&*include_apps_order_by*=-state,-date)

https://github.com/cloudfoundry/cc-api-v3-style-guide#proposal
Would useful to consider I18N of user-facing messages. Cf related thread
for service broker error messages at
http://cf-dev.70369.x6.nabble.com/cf-dev-Announcing-Experimental-support-for-Asynchronous-Service-Operations-tp287p1471.html
May be the CC API could accept a "Accept-Language: zh_Hans" header and try
to return localized messages when available in the accepted locale.

Thanks,

Guillaume.

On Wed, Sep 2, 2015 at 6:44 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Thanks James, I've just corrected the three issues you've noted so far


Re: So many hard-coded dropsonde destinations to metrons

Warren Fernandes
 

Dropsonde is a go library that allows the CF components using it to emit logs and metrics. The current flow for CF components is to emit their logs and metrics to their local metron agent which then forwards them to the Doppler servers in Loggregator. The metron agents only listen on the local interface and immediately signs the messages before sending them off to the Dopplers. So for now, the destination parameter for dropsonde will always point to the local metron agent.

Here is some more info on Metron https://github.com/cloudfoundry/loggregator/tree/develop/src/metron
Here is some more info on Dropsonde https://github.com/cloudfoundry/dropsonde


Re: Announcing Experimental support for Asynchronous Service Operations

Guillaume Berche
 

Great, thanks Dieu.

Guillaume.

On Fri, Sep 4, 2015 at 8:44 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Thanks Guillaume for the feedback. I've now gathered enough feedback to
bring async operations out of the experimental phase and bump the service
broker api version.
I've added stories to the CAPI backlog [1] and we'll get the diagram
updated too.

Localized error messages is not something we are looking to work on right
now. I believe there was a previous attempt to have CC errors localized
that ended up not being merged due to issues with the way v2 constructed
error messages and not being backwards compatible. As these descriptions
passed from brokers via the last_operation end point don't go that route,
there's perhaps a path forward there.
Happy to discuss if it's work that anyone is interested in taking on via
PR.

-Dieu
CF CAPI PM

[1] https://www.pivotaltracker.com/epic/show/2058352




On Wed, Sep 2, 2015 at 5:00 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Dieu for your response.

We have successfully implemented an async service broker for out internal
dbaas [1], [2] which db farms provisionning sometimes takes longer than
30s.

Concerning improvement suggestions on the documentation, I could only
spot an inconsistency on the sequence diagram, where the last operation
description is mismatching between broker response (1/3 nodes") and CC api
response ("40% complete") whereas the 'description' is a string which
should be returned as is. Hard to propose a PR on that since the source
file for this diagram does not seem available under docs-services [4]. BTW,
It would be great if bookbinder would support rendering diagrams from a
text format such as plantuml [5], or rely on plantuml public service [6]
for such rendering.

Wouldn't is make sense to exit the experimental status of the async api,
even if it's not feature complete ? i.e. considering the api is stable
enough and won't change in an incompatible maneer soon, thereby enabling
clients such as cf-java-client to rely on them.

One other potential improvement I see to the API would be to support
localized user-facing operation status description. Having the CLI being
I18Ned but brokers enable to return user facing messages in the user
language seems limiting. Maybe it could be the case of having the CLI add a
usual 'Accept-Language: zh_Hans" matching the current CLI locale, and
the CC propagating this header in the last_operation broker endpoint [7] so
that they can return the status message in the smae language when
translations are available.

Thanks,

Guillaume.

[1]
https://github.com/Orange-OpenSource/elpaaso-brokers/blob/master/cf-service-broker-dbaas/src/main/java/com/orange/clara/cloud/cf/servicebroker/dbaas/service/DbaasServiceInstanceService.java#L60
[2]
https://github.com/Orange-OpenSource/elpaaso-brokers/blob/a3f150fc7d3bb889875aac202496a4f63efc3595/cf-service-broker-dbaas/src/main/java/com/orange/clara/cloud/cf/servicebroker/dbaas/service/DbaasServiceInstanceService.java#L67-L73
[3]
http://docs.cloudfoundry.org/services/images/async-service-broker-flow.png
[4]
https://github.com/cloudfoundry/docs-services/blob/master/images/async-service-broker-flow.png
[5] http://plantuml.com/sequence.html
[6] http://plantuml.com/plantuml/
[7]
http://docs.cloudfoundry.org/services/asynchronous-operations.html#polling

On Tue, Sep 1, 2015 at 5:50 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Guillaume,

We are looking for a couple more pieces of feedback. All feedback I've
received so far has been positive.

There was one report recently from Robert Moss about being able to
provide the dashboard_url asynchronously instead of part of the original
response [1].
I'm also considering whether that needs to be addressed prior to marking
the feature complete, or if it should be a separate/additive change to the
service broker api.

If you've had success with the current implementation, I would be
greatly interested in hearing that.

-Dieu

[1]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/LJ26K22WG7OJCAIXWYPTJQKELVAUBUZC/

On Tue, Sep 1, 2015 at 5:20 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I'm wondering whether the experimental async service broker api is now
ready to become official, or whether the CAPI team and PMs are still
lacking feedback or have some outstanding issues that need to be addressed
before calling the spec official? I was not able to spot any async-related
stories in the CAPI backlog [1]

We have a pending PR in cf-java-client [2] which is waiting for the
async broker spec to be made official.

Thanks in advance,

Guillaume.

[1] https://www.pivotaltracker.com/n/projects/966314
[2]
https://github.com/cloudfoundry/cf-java-client/pull/282#issuecomment-115874984

On Fri, Jun 5, 2015 at 9:21 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i'm very happy to see this work delivered as the 60 second limit has
come up so often as a pain point in the past. great job to all who
contributed!

On Wed, Jun 3, 2015 at 5:05 PM, Onsi Fakhouri <ofakhouri(a)pivotal.io>
wrote:

Well done Services API! This is an awesome milestone!

On Wed, Jun 3, 2015 at 5:04 PM, Chip Childers <
cchilders(a)cloudfoundry.org> wrote:

Awesome news! Long time coming, and it opens up a whole world of
additional capabilities for users.

Nice work everyone!



On Jun 4, 2015, at 9:00 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

On behalf of the Services API team, including Dojo participants from
IBM and SAP, I'm pleased to announce experimental availability and
published documentation for this much-anticipated feature.

As of cf-release v208 and CLI v6.11.1, Cloud Foundry now supports an
enhanced service broker integration in support of long-running
provisioning, update, and delete operations. This significantly broadens
the supported use cases for Cloud Foundry Marketplace Services, and I can't
wait to hear what creative things the ecosystem does with it. Provision
VMs, orchestrate clusters, install software, move data... yes, your broker
can even open support tickets to have those things done manually!

This feature is currently considered experimental, as we'd like you
all to review our docs, try out the feature, and give us feedback. We very
interested to hear about any confusion in the docs or the UX, and any
sticky issues you encounter in implementation. Our goal is for our docs
enable a painless, intuitive (can we hope for joyful?) implementation
experience.

We have not bumped the broker API yet for this feature. You'll
notice that our documentation for the feature is separate from the stable
API docs at this point. Once we're confident in the design (we're relying
on your feedback!), we'll bump the broker API version, move the docs for
asynchronous operations into the stable docs, AND implement support for
asynchronous bind/create-key and unbind/delete-key.

Documentation:
- http://docs.cloudfoundry.org/services/asynchronous-operations.html
- http://docs.cloudfoundry.org/services/api.html
Example broker for AWS (contributed by IBM):
- http://docs.cloudfoundry.org/services/examples.html
- https://github.com/cloudfoundry-samples/go_service_broker
Demo of the feature presented at CF Summit 2015:
- https://youtu.be/Ij5KSKrAq9Q

tl;dr

Cloud Foundry expects broker responses within 60 seconds. Now a
broker can return an immediate response indicating that a provision,
update, or delete operation is in progress. Cloud Foundry then returns a
similar response to the client, and begins polling the broker for the
status of the operation. Users, via API clients, can discover the status of
the operation ("in progress", "succeeded", or "failed"), and brokers can
provide user-facing messages in response to each poll which are exposed to
users (e.g. "VMs provisioned, installing software, 30% complete").

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: When will dea be replaced by diego?

Layne Peng
 

I think what he ask is, when the Diego-release will merge to cf-release. And also no need to install cf cli diego plugin, no need to enabe-diego to your app, then start. For the https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#a-detailed-transition-timeline . it is said to be mid-september, is it right?


Re: When will dea be replaced by diego?

James Bayer
 

you can use diego today in place of DEAs.

diego requires the other cf components other than DEAs and Health Manager.

On Sun, Sep 6, 2015 at 11:49 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:

Hi,



Is there any plan when dea will not be supported and be replaced by diego?
Can I push application into diego without CF alongaside?



Any help will be appreciated.



Thanks,

Maggie
--
Thank you,

James Bayer


Re: How to execute multiple CF REST methods with an unique authentication

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Currently,

If I execute 2 operations with the same token, I receive the following message:

it.only("Using Login to execute 2 REST operations", function () {
this.timeout(2500);

CloudFoundry.setEndPoint(endPoint);

var token_endpoint = null;
var refresh_token = null;
return CloudFoundry.getInfo().then(function (result) {
token_endpoint = result.token_endpoint;
return CloudFoundry.login(token_endpoint, username, password);
}).then(function (result) {
return CloudFoundryApps.getApps(result.token_type, result.access_token);
}).then(function (result) {
return CloudFoundryApps.getApps(result.token_type, result.access_token);
}).then(function (result) {
console.log(result);
expect(true).to.equal(true);
});
});

Tests Response:

1) Cloud Foundry Using Login to execute 2 REST operations:
Error: the string "{\n \"code\": 10002,\n \"description\": \"Authenticati
on error\",\n \"error_code\": \"CF-NotAuthenticated\"\n}\n" was thrown, throw a
n Error :)


How to execute multiple CF REST methods with an unique authentication

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Hi,

Currently, I am developing a Web Application which interacts with CF REST API. At the moment, I have to log in the system every time when I execute any REST operation.

Example:

function createApp(appName, buildPack) {

var token_endpoint = null;
var app_guid = null;
var space_guid = null;
var domain_guid = null;
var routeName = null;
var route_guid = null;
var route_create_flag = false;

return new Promise(function (resolve, reject) {

CloudFoundry.getInfo().then(function (result) {
token_endpoint = result.token_endpoint;

return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundrySpaces.getSpaces(result.token_type, result.access_token).then(function (result) {
return new Promise(function (resolve) {
space_guid = result.resources[0].metadata.guid;
//console.log("Space guid: ", space_guid);
return resolve();
});
});
});
//Does exist the application?
}).then(function () {
var filter = {
'q': 'name:' + appName,
'inline-relations-depth': 1
};
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundrySpaces.getSpaceApps(result.token_type, result.access_token, space_guid, filter);
});
}).then(function (result) {

//If exist the application, Stop
if (result.total_results === 1) {
console.log("Stop App: " + appName);
app_guid = result.resources[0].metadata.guid;
console.log("App guid: ", app_guid);
console.log(result.resources[0].entity.name);

return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryApps.stopApp(result.token_type, result.access_token, app_guid);
});
}else {
//console.log("Create App");
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryApps.createApp(result.token_type, result.access_token, appName, space_guid, buildPack).then(function (result) {
return new Promise(function (resolve) {
//console.log(result);
app_guid = result.metadata.guid;
return resolve();
});
});
});
}
}).then(function () {
//TODO: How to make the inference?
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryDomains.getSharedDomains(result.token_type, result.access_token);
});
}).then(function () {
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryDomains.getDomains(result.token_type, result.access_token).then(function (result) {
return new Promise(function (resolve) {
domain_guid = result.resources[0].metadata.guid;
//console.log("Domain guid: " , domain_guid);
return resolve();
});
});
});
}).then(function () {
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryRoutes.checkRoute(result.token_type, result.access_token, appName, domain_guid).then(function (result) {
return new Promise(function (resolve) {
if (result.total_results === 1) {
console.log("Exist a Route");
//console.log(result.resources);
route_guid = result.resources[0].metadata.guid;
console.log("Route guid: ", route_guid);
return resolve(result);
}else {
//Add Route
route_create_flag = true; //Workaround
return resolve();
}

});
});
});
}).then(function () {
//TODO: Refactor syntax to code in the right place
if (route_create_flag) {
//Add Route
//console.log("Create a Route");
routeName = appName;
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryRoutes.addRoute(result.token_type, result.access_token, domain_guid, space_guid, routeName).then(function (result) {
return new Promise(function (resolve) {
//console.log(result);
route_guid = result.metadata.guid;
return resolve(result);
});
});
});
}else {
return new Promise(function (resolve) {
return resolve();
});
}
}).then(function () {
return CloudFoundry.login(token_endpoint, username, password).then(function (result) {
return CloudFoundryApps.associateRoute(result.token_type, result.access_token, appName, app_guid, domain_guid, space_guid, route_guid);
});
}).then(function (result) {
//console.log(result);
return resolve(result);
}).catch(function (reason) {
console.error("Error: " + reason);
return reject(reason);
});

});

}

The login method sends the following parameters in the requests to uaa:

var options = {
method: 'POST',
url: url,
headers: {
'Authorization': 'Basic Y2Y6',
'Content-Type': 'application/x-www-form-urlencoded'
},
form : {
grant_type: "password",
client_id: "cf",
username: username,
password: password
}
};

When I log into CF I receive the following response:

{ access_token: 'eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI4YzRkMDRmMC1iYmU4LTRjNWUtODFmMS
04Y2M5ZDc4Y2ZhZDciLCJzdWIiOiIwNTQ0ODY5MS04YWU1LTQwZDktODU2Mi1kOWI4N2E2MTJiMzMiLC
JzY29wZSI6WyJzY2ltLnJlYWQiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsIm
Nsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2Nvbn
Ryb2xsZXIucmVhZCIsImRvcHBsZXIuZmlyZWhvc2UiXSwiY2xpZW50X2lkIjoiY2YiLCJjaWQiOiJjZi
IsImF6cCI6ImNmIiwiZ3JhbnRfdHlwZSI6InBhc3N3b3JkIiwidXNlcl9pZCI6IjA1NDQ4NjkxLThhZT
UtNDBkOS04NTYyLWQ5Yjg3YTYxMmIzMyIsInVzZXJfbmFtZSI6ImFkbWluIiwiZW1haWwiOiJhZG1pbi
IsImlhdCI6MTQ0MTYxODAyOCwiZXhwIjoxNDQxNjE4NjI4LCJpc3MiOiJodHRwczovL3VhYS4zNy40OC
44MS4xNzAueGlwLmlvL29hdXRoL3Rva2VuIiwiYXVkIjpbImNmIiwic2NpbSIsImNsb3VkX2NvbnRyb2
xsZXIiLCJwYXNzd29yZCIsIm9wZW5pZCIsImRvcHBsZXIiXX0.W8_LC1g5eNM8NWVh68Pfx5FKVQe6C6
bvEulELHG9_9qsy3A3S50tUKNFQNjIhBPR18DyAJvs5iQy1pEcU2AciRa_3w83nLnzsgIJgwEFQ4mlCK
j9ovpsE55cM2-5JpFgBi8b-em-ce4WwSvFN9y1BhOAc2njNdJKJllR5Gh5kPE',
token_type: 'bearer',
refresh_token: 'eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI0ZGViNjE3Yy00NDMxLTQzYTQtODU5Y
y1hNWQ1MmIwNTI4ZTIiLCJzdWIiOiIwNTQ0ODY5MS04YWU1LTQwZDktODU2Mi1kOWI4N2E2MTJiMzMiL
CJzY29wZSI6WyJzY2ltLnJlYWQiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsI
mNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2Nvb
nRyb2xsZXIucmVhZCIsImRvcHBsZXIuZmlyZWhvc2UiXSwiaWF0IjoxNDQxNjE4MDI4LCJleHAiOjE0N
DQyMTAwMjgsImNpZCI6ImNmIiwiaXNzIjoiaHR0cHM6Ly91YWEuMzcuNDguODEuMTcwLnhpcC5pby9vY
XV0aC90b2tlbiIsImdyYW50X3R5cGUiOiJwYXNzd29yZCIsInVzZXJfbmFtZSI6ImFkbWluIiwidXNlc
l9pZCI6IjA1NDQ4NjkxLThhZTUtNDBkOS04NTYyLWQ5Yjg3YTYxMmIzMyIsImF1ZCI6WyJjZiIsInNja
W0iLCJjbG91ZF9jb250cm9sbGVyIiwicGFzc3dvcmQiLCJvcGVuaWQiLCJkb3BwbGVyIl19.ji7tWinO
U1Wq6Y77ygSdF12ETG_TD9xQf82bVU01si3OZ9Ou4FG_HWv-CvQlJ7yh1KpH8emGsz92Omu45YEOyNU7
dOIRIMtP7u2DO_aWb2mzMBOwVnpFongyRkz_lbnqPgixW88v1DOJ2PY5KYoNxzxbIP98UX2xht6XXSqO
qww',
expires_in: 599,
scope: 'scim.read cloud_controller.admin scim.write cloud_controller.write pas
sword.write openid cloud_controller.read doppler.firehose',
jti: '8c4d04f0-bbe8-4c5e-81f1-8cc9d78cfad7' }


How to use the refresh token?
It is possible to reuse some fields of login response to reuse the authentication?

My idea could be:

1. Login in the system.
2. Call CF API n times, sending some kind of token.

At the moment, I send in the authorization header the auth token:

var options = {
method: 'GET',
url: url,
headers: {
'Authorization': token_type + ' ' + access_token
}
};

Many thanks in advance.

Juan Antonio


valid org, space and service instance name?

Buchen, Andreas <andreas.buchen@...>
 

Hi,
 
do you know what makes a valid org, space and service instance name?
 
I was able to find regular expressions for org and space (see below).
For service instance names I was able to find a length restriction.
 
From the database migrations, it is unclear to me to what number of characters it is limited on the database.
 
 
Andreas.

 
 
 
# Org
 
https://github.com/cloudfoundry/cloud_controller_ng/blob/0fc14205ce043c1f22a398c67ad080326f9ad115/app/models/runtime/organization.rb
ORG_NAME_REGEX = /\A[[:alnum:][:punct:][:print:]]+\Z/.freeze
 
# Space
 
https://github.com/cloudfoundry/cloud_controller_ng/blob/0fc14205ce043c1f22a398c67ad080326f9ad115/app/models/runtime/space.rb
SPACE_NAME_REGEX = /\A[[:alnum:][:punct:][:print:]]+\Z/.freeze
 
# Service Instance
 
validates_max_length 50, :name
https://github.com/cloudfoundry/cloud_controller_ng/blob/0fc14205ce043c1f22a398c67ad080326f9ad115/app/models/services/service_instance.rb#L81
 
# Database Migrations

https://github.com/cloudfoundry/cloud_controller_ng/blob/0fc14205ce043c1f22a398c67ad080326f9ad115/db/migrations/20130131184954_new_initial_schema.rb


Re: Application only starts when a bogus service is attached

Fabien LEBRERE
 

Hi,


What version of the Java build pack do you have installed? `cf
buildpacks`? What does your `cf push` command & manifest.yml look like?
The version is : v3.1 | https://github.com/cloudfoundry/java-buildpack.git#7a538fb
There is not manifest.yml

The push cmd was : cf push sampletest -p sample.war

And the logs :
Starting app sampletest in org dinb / space development as admin...
-----> Downloaded app package (8.0K)
-----> Java Buildpack Version: v3.1 | https://github.com/cloudfoundry/java-buildpack.git#7a538fb
-----> Downloading Open Jdk JRE 1.8.0_60 from https://download.run.pivotal.io/openjdk/trusty/x86_64/openjdk-1.8.0_60.tar.gz (7.4s)
Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.0s)
-----> Downloading Open JDK Like Memory Calculator 1.1.1_RELEASE from https://download.run.pivotal.io/memory-calculator/trusty/x86_64/memory-calculator-1.1.1_RELEASE (0.9s)
Memory Settings: -Xmx768M -Xms768M -XX:MaxMetaspaceSize=104857K -XX:MetaspaceSize=104857K -Xss1M
-----> Downloading Tomcat Instance 8.0.24 from https://download.run.pivotal.io/tomcat/tomcat-8.0.24.tar.gz (4.1s)
Expanding Tomcat to .java-buildpack/tomcat (0.1s)
-----> Downloading Tomcat Lifecycle Support 2.4.0_RELEASE from https://download.run.pivotal.io/tomcat-lifecycle-support/tomcat-lifecycle-support-2.4.0_RELEASE.jar (0.2s)
-----> Downloading Tomcat Logging Support 2.4.0_RELEASE from https://download.run.pivotal.io/tomcat-logging-support/tomcat-logging-support-2.4.0_RELEASE.jar (0.2s)
-----> Downloading Tomcat Access Logging Support 2.4.0_RELEASE from https://download.run.pivotal.io/tomcat-access-logging-support/tomcat-access-logging-support-2.4.0_RELEASE.jar (0.2s)

-----> Uploading droplet (51M)

0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 failing
FAILED
Start unsuccessful



What do you mean by "fake"? Is it an actual service attached to a DB? Is
it a user provided service with no info?
It's a real service service, but not necessary for the app, like mongoDB (small) service
The binding it's just done for the fun, It's sure it's a strange workaround ;)



Some suggestions for troubleshooting...

1.) Run `cf logs <app>` in a second terminal. Then run `cf push`. After
the build pack completes, you should see a line that says CF is starting
the app. If you see no logging between that and the notice that the app
exited, you might try this. Sometimes when an app exits too fast, logging
is lost.

http://support.run.pivotal.io/entries/82506749-Help-My-app-is-crashing-an...
I have the trace of the app ;)
If I remove the service, the last log line after a push is :
o.s.web.context.ContextLoader - Root WebApplicationContext: initialization completed in 9202 ms
If I add the service, the last log line after a push is :
[CONTAINER] org.apache.catalina.startup.Catalina INFO Server startup in 10731 ms



2.) Because it's a Java app, you might also try this.

http://support.run.pivotal.io/entries/59869725-Java-Web-Applications-Slow...

(sorry for the PWS links, those should be relevant for anyone running CF
though)
Solve the problem !!!!



You might try the samples for Tomcat 8, since that's what the Java build
pack has been deploying for a while.

Dan


When will dea be replaced by diego?

MaggieMeng
 

Hi,

Is there any plan when dea will not be supported and be replaced by diego? Can I push application into diego without CF alongaside?

Any help will be appreciated.

Thanks,
Maggie


Re: Placement Pools

Noburou TANIGUCHI
 

I'll take on getting the proposal for isolation groups shared with cf-dev,
hopefully, in the next couple of weeks.
Great!

Is there any big change from
https://docs.google.com/document/d/1GNjQwGBh0BvfAYpX0LTUYn6h4oLz7v4P9pNy0xHZtMw/edit#
?


Dieu Cao wrote
Yes, I was just talking with Onsi and Mark Kropf about this yesterday and
plan to submit a talk on this with Mark Kropf for cf summit berlin.

I'll take on getting the proposal for isolation groups shared with cf-dev,
hopefully, in the next couple of weeks.

-Dieu
CF CAPI PM

On Friday, September 4, 2015, James Bayer &lt;
jbayer@
&gt; wrote:

i believe dieu is working on this in preparate for cf summit in berlin.
dieu, did i understand that correctly?

On Thu, Sep 3, 2015 at 4:50 PM, Carlo Alberto Ferraris <
cafxx@
wrote:

James, Onsi,
we’re also looking forward to this, for we have some peculiar
infrastructure requirements.

Carlo

On Aug 29, 2015, at 2:51 AM, James Bayer &lt;
jbayer@
&gt; wrote:

we've been using a new term for the same concept we've previously
labeled
placement pools called "isolation groups".

onsi has been working on some documentation for what this may look like
and the requirements, but the work has not started. i believe onsi will
share something soon.

so today, the way to accomplish this need to place apps on specific
infrastructure is to use separate CF installations.

On Fri, Aug 28, 2015 at 8:50 AM, Matt Cholick &lt;
cholick@
&gt; wrote:

More than a year ago, there was some discussion and a proposal around
adding placement pools so cloud foundry admins could better target how
applications were placed on runners:

https://docs.google.com/document/d/1GNjQwGBh0BvfAYpX0LTUYn6h4oLz7v4P9pNy0xHZtMw/edit#

Did this work gain traction? I've looked through the release notes as
well as MEGA and CF Diego's public trackers and don't see stories for
this
work either done or planned, though it could also be that I'm just not
finding it.

My goal is to place canary apps in specifically Z1 or Z2, as well as
place some internally used apps that, for networking reasons, should be
in
one zone or the other.

-Matt Cholick


--
Thank you,

James Bayer



--
Thank you,

James Bayer




-----
I'm not a ...
noburou taniguchi
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Placement-Pools-tp1394p1521.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: [lattice] v0.4.0

James Bayer
 

great release team!

i love the new tcp router functionality. this will unlock many workloads in
the platform and i love that lattice gives us a way to use it early before
the full cloud foundry feature is ready.

although confusing at first why i was getting the error message on the main
repo when i did the standard workflow to update, i now understand the
release bundles. i would encourage you to put something in the Vagrantfile
provision script in the root of the repo that says "Please use the new
release bundle approach as of v0.4.0 and higher as documented here: [link]".

On Fri, Sep 4, 2015 at 12:30 PM, Marco Nicosia <mnicosia(a)pivotal.io> wrote:

On behalf of the Lattice AND the Routing teams, I am pleased to announce
v0.4.0 of Lattice!

We've taken some time off to convert our pipelines from GoCD to Concourse,
and the Routing team has integrated the TCP Router into Lattice. This is
something we've been looking forward to, please check it out and give us
feedback!

The full release notes are included below.

I'm also happy to announce David Wadden as the new Product Manager for
Lattice. David's been the anchor of the project team for the last 6 months,
so he's well-equipped to step into the position. Please welcome in his new
role, and thank you David!

As always:
- If you think you've found a bug, please file a GitHub issue.
- If you have a contribution, we'd be happy to give you feedback via a
Pull Request.
- You can track our prioritized queue of work at:
http://bit.ly/lattice-tracker

--
Marco Nicosia && David Wadden


---------- Forwarded message ----------
From: Marco Nicosia <notifications(a)github.com>
Date: Fri, Sep 4, 2015 at 11:12 AM
Subject: [lattice] v0.4.0
To: cloudfoundry-incubator/lattice <lattice(a)noreply.github.com>


v0.4.0

Beginning with v0.4.1, direct access to Lattice cells will be restricted
to private addresses within the cluster.

Introducing TCP Router

TCP Router is a collection of components that balances traffic across one
or more instances of an application. Unlike gorouter, tcp-router balances
traffic other than HTTP, such as mysql, redis, or mongodb. Using ltc, a
user defines a route from an external port on the Lattice brain to an
exposed port on the application container. Under the hood, tcp-emitter
regularly updates HAProxy <http://www.haproxy.org/> with the TCP routes
defined on the Lattice cluster.

- #172 <https://github.com/cloudfoundry-incubator/lattice/pull/172>
#182 <https://github.com/cloudfoundry-incubator/lattice/pull/182> #191
<https://github.com/cloudfoundry-incubator/lattice/pull/191>: Merge
TCP Router functionality [#101089176
<https://www.pivotaltracker.com/story/show/101089176>] [#101699282
<https://www.pivotaltracker.com/story/show/101699282>] [#102296358
<https://www.pivotaltracker.com/story/show/102296358>]
- [image: :+1:] Big thanks to the Routing team for their
contributions! @shalako <https://github.com/shalako> @fordaz
<https://github.com/fordaz> @atulkc <https://github.com/atulkc>
- --routes no longer works on ltc create and ltc launch-droplet.
- Use the --http-routes flag to define HTTP routes for an app. [
#100758692 <https://www.pivotaltracker.com/story/show/100758692>] [
#100436212 <https://www.pivotaltracker.com/story/show/100436212>]
- --http-routes takes a comma-delimited set of ROUTE:CONTAINER_PORT
- This is reversed from --routes (*breaking change*)
- New --tcp-routes flag takes comma-delimited set of
EXTERNAL_PORT:CONTAINER_PORT
- Multiple TCP routes can route to same container port. [#101697408
<https://www.pivotaltracker.com/story/show/101697408>]
- ltc update changes HTTP and/or TCP routes for a running application.
[#98240702 <https://www.pivotaltracker.com/story/show/98240702>]
- Replaces ltc update-routes (will be removed in a future release).
- ltc status and ltc list show TCP routes [#100258924
<https://www.pivotaltracker.com/story/show/100258924>] [#100258722
<https://www.pivotaltracker.com/story/show/100258722>]

New Distribution Bundles

With the recent conversion to Concourse <http://concourse.ci/> as our CI
platform, we took the opportunity to change the way we distribute Lattice
-- no more git checkout; vagrant up. Starting with *v0.4.0*, we
distribute a *bundle* (links below) that contains ltc along with the
vagrant/terraform files needed to launch Lattice.

- Distribute Lattice via bundles [#101458202
<https://www.pivotaltracker.com/story/show/101458202>] [#101314108
<https://www.pivotaltracker.com/story/show/101314108>] [#101314112
<https://www.pivotaltracker.com/story/show/101314112>]

New Features

- ltc target --s3 uses an S3 bucket as the droplet store [#100236758
<https://www.pivotaltracker.com/story/show/100236758>] [#100237448
<https://www.pivotaltracker.com/story/show/100237448>]
- Allows multiple developers to share droplets
- Persists droplets across subsequent Lattice deployments
- ltc create --monitor-command uses a custom healthcheck command [
#91461922 <https://www.pivotaltracker.com/story/show/91461922>]

Usability Fixes

- ltc target times out when a connection to the blob store hangs [
#101164182 <https://www.pivotaltracker.com/story/show/101164182>]
- No longer downloads RootFS at provision-time on Vagrant and AWS [
#101844068 <https://www.pivotaltracker.com/story/show/101844068>] [
#101844098 <https://www.pivotaltracker.com/story/show/101844098>]
- Upgraded base Ubuntu image to 14.04.3 [#102162900
<https://www.pivotaltracker.com/story/show/102162900>]
- Document
<https://github.com/cloudfoundry-incubator/lattice/tree/v0.4.0#vagrant-ip-conflict-errors>
how to diagnose and resolve multiple vagrant instances running [
#101992188 <https://www.pivotaltracker.com/story/show/101992188>]

For Developers

- ci.lattice.cf shows the current build status [#101284204
<https://www.pivotaltracker.com/story/show/101284204>]
- As part of our migration to Concourse, we now track master. Moving
forward, please submit any PRs against the *master* branch. [#101834808
<https://www.pivotaltracker.com/story/show/101834808>]


View it on GitHub
<https://github.com/cloudfoundry-incubator/lattice/releases/tag/v0.4.0>.

--
Thank you,

James Bayer


Re: Generic data points for dropsonde

James Bayer
 

after understanding ben's proposal of what i would call an extensible
generic point versus the status quo of metrics that are actually hard-coded
in software on by the metric producer and the metric consumer, i
immediately gravitated toward the approach by ben.

cloud foundry has really benefited from extensibility in these examples:

* diego lifecycles
* app buildpacks
* app docker images
* app as windows build artifact
* service brokers
* cf cli plugins
* collector plugins
* firehose nozzles
* diego route emitters
* garden backends
* bosh cli plugins
* bosh releases
* external bosh CPIs
* bosh health monitor plugins

let me know if there are other points of extension i'm missing.

in most cases, the initial implementations required cloud foundry system
components to change software to support additional extensibility, and some
of the examples above still require that and it's an issue in frustration
as someone with an idea to explore needs to persuade the cf maintaining
team to process a pull request or complete work on an area. i see ben's
proposal as making an extremely valuable additional point of extension for
creating application and system metrics that benefits the entire cloud
foundry ecosystem.

i am sympathetic to the question raised by dwayne around how large the
messages will be. it would seem that we could consider an upper bound on
the number of attributes supported by looking at the types of metrics that
would be expressed. the redis info point is already 84 attributes for
example.

all of the following seem related to scaling considerations off the top of
my head:
* how large an individual metric may be
* at what rate the platform should support producers sending metrics
* what platform quality of service to provide (lossiness or not, back
pressure, rate limiting, etc)
* what type of clients to the metrics are supported and any limitations
related to that.
* whether there is tenant variability in some of the dimensions above. for
example a system metric might have a higher SLA than an app metric

should we consider putting a boundary on the "how large an individual
metric may be" by limiting the initial implementation to a number of
attributes (that we could change later or make configurable?).

i'm personally really excited about this new set of extensibility being
proposed and the creative things people will do with it. having loggregator
as a built-in system component versus a bolt-on is already such a great
capability compared with other platforms and i see investments to make it
more extensible and apply to more scenarios as making cloud foundry more
valuable and more fun to use.

On Fri, Sep 4, 2015 at 10:52 AM, Benjamin Black <bblack(a)pivotal.io> wrote:

johannes,

the problem of upstream schema changes causing downstream change or
breakage is the current situation: every addition of a metric type implies
a change to the dropsonde-protocol requiring everything downstream to be
updated.

the schema concerns are similar. currently there is no schema whatsoever
beyond the very fine grained "this is a name and this is a value". this
means every implementation of redis info export, for example, can, and
almost certainly will, be different. this results in every downstream
consumer having to know every possible variant or to only support specific
variants, both exactly the problem you are looking to avoid.

i share the core concern regarding ensuring points are "sufficiently" self
describing. however, there is no clear line delineating what is sufficient.
the current proposal pushes almost everything out to schema. we could
imagine a change to the attributes that includes what an attribute is
(gauge, counter, etc), what the units are for the attribute, and so on.

it is critical that we balance the complexity of the points against
complexity of the consumers as there is no free lunch here. which specific
functionality would you want to see in the generic points to achieve the
balance you prefer?


b



On Wed, Sep 2, 2015 at 2:07 PM, Johannes Tuchscherer <
jtuchscherer(a)pivotal.io> wrote:

The current way of sending metrics as either Values or Counters through
the pipeline makes the development of a downstream consumer (=nozzle)
pretty easy. If you look at the datadog nozzle[0], it just takes all
ValueMetrics and Counters and sends them off to datadog. The nozzle does
not have to know anything about these metrics (e.g. their origin, name, or
layout).

Adding a new way to send metrics as a nested object would make the
downstream implementation certainly more complicated. In that case, the
nozzle developer has to know what metrics are included inside the generic
point (basically the schema of the metric) and treat each point
accordingly. For example, if I were to write a nozzle that emits metrics to
Graphite with a StatsD client (like it is done here[1]), I need to know if
my int64 value is a Gauge or a Counter. Also, my consumer is under constant
risk of breaking when the upstream schema changes.

We are already facing this problem with the container metrics. But at
least the container metrics are in a defined format that is well documented
and not likely to change.

I agree with you, though, the the dropsonde protocol could use a
mechanism for easier extension. Having a GenericPoint and/or GenericEvent
seems like a good idea that I whole-heartedly support. I would just like to
stay away from nested metrics. I think the cost of adding more logic into
the downstream consumer (and making it harder to maintain) is not worth the
benefit of a more concise metric transport.


[0] https://github.com/cloudfoundry-incubator/datadog-firehose-nozzle
[1] https://github.com/CloudCredo/graphite-nozzle

On Tue, Sep 1, 2015 at 5:52 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

great questions, dwayne.

1) the partition key is intended to be used in a similar manner to
partitioners in distributed systems like cassandra or kafka. the specific
behavior i would like to make part of the contract is two-fold: that all
data with the same key is routed to the same partition and that all data in
a partition is FIFO (meaning no ordering guarantees beyond arrival time).

this could help with the multi-line log problem by ensuring a single
consumer will receive all lines for a given log entry in order, allowing
simple reassembly. however, the lines might be interleaved with other lines
with the same key or even other keys that happen to map to the same
partition, so the consumer does require a bit of intelligence. this was
actually one of the driving scenarios for adding the key.

2) i expect typical points to be in the hundreds of bytes to a few KB.
if we find ourselves regularly needing much larger points, especially near
that 64KB limit, i'd look to the JSON representation as the hierarchical
structure is more efficiently managed there.


b




On Tue, Sep 1, 2015 at 4:42 PM, <dschultz(a)pivotal.io> wrote:

Hi Ben,

I was wondering if you could give a concrete use case for the partition
key functionality.

In particular I am interested in how we solve multi line log entries. I
think it would be better to solve it by keeping all the data (the multiple
lines) together throughout the logging/metrics pipeline, but could see how
something like a partition key might help keep the data together as well.

Second question: how large do you see these point messages getting
(average and max)? There are still several stages of the logging/metrics
pipeline that use UDP with a standard 64K size limit.

Thanks,
Dwayne

On Aug 28, 2015, at 4:54 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

All,

The existing dropsonde protocol uses a different message type for each
event type. HttpStart, HttpStop, ContainerMetrics, and so on are all
distinct types in the protocol definition. This requires protocol changes
to introduce any new event type, making such changes very expensive. We've
been working for the past few weeks on an addition to the dropsonde
protocol to support easier future extension to new types of events and to
make it easier for users to define their own events.

The document linked below [1] describes a generic data point message
capable of carrying multi-dimensional, multi-metric points as sets of
name/value pairs. This new message is expected to be added as an additional
entry in the existing dropsonde protocol metric type enum. Things are now
at a point where we'd like to get feedback from the community before moving
forward with implementation.

Please contribute your thoughts on the document in whichever way you
are most comfortable: comments on the document, email here, or email
directly to me. If you comment on the document, please make sure you are
logged in so we can keep track of who is asking for what. Your views are
not just appreciated, but critical to the continued health and success of
the Cloud Foundry community. Thank you!


b

[1]
https://docs.google.com/document/d/1SzvT1BjrBPqUw6zfSYYFfaW9vX_dTZZjn5sl2nxB6Bc/edit?usp=sharing




--
Thank you,

James Bayer


Re: So many hard-coded dropsonde destinations to metrons

Noburou TANIGUCHI
 

Sorry, all
I used the "Raw text" function in Nabble, but it is not suitable for other
environment.

Thanks for telling, Amit.


Amit Gupta wrote
Oddly, I can see your list on nabble here:

http://cf-dev.70369.x6.nabble.com/So-many-hard-coded-dropsonde-destinations-to-metrons-tp1474.html

But it's just blank in the email, and also on the cloudfoundry.org
archive:

https://lists.cloudfoundry.org/archives/list/
cf-dev(a).cloudfoundry
/thread/73TWLI6BVETB5PCI4CBKXNCLUZRJJIIV/

Here's the list for anyone else trying to read it:

garden-linux-release/src/github.com/cloudfoundry/dropsonde/dropsonde.go:
10:// dropsonde.Initialize("localhost:3457", origins...)

garden-linux-release/src/
github.com/cloudfoundry-incubator/garden-linux/main.go:
175: "localhost:3457",

github.com/cloudfoundry-incubator/auctioneer/cmd/auctioneer/main.go:
84: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/bbs/cmd/bbs/main.go:
67: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/converger/cmd/converger/main.go:
82: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/diego-ssh/cmd/ssh-proxy/main.go:
68: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/file-server/cmd/file-server/main.go:
59: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/garden-linux/old/main.go:
178: "localhost:3457",

github.com/cloudfoundry-incubator/nsync/cmd/nsync-bulker/main.go:
109: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/nsync/cmd/nsync-listener/main.go:
53: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/receptor/cmd/receptor/main.go:
120: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/rep/cmd/rep/main.go:
166: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/route-emitter/cmd/route-emitter/main.go:
91: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/runtime-metrics-server/cmd/runtime-metrics-server/main.go
:
65: "localhost:3457",

github.com/cloudfoundry-incubator/stager/cmd/stager/main.go:
89: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/tps/cmd/tps-listener/main.go:
53: dropsondeDestination = "localhost:3457"

github.com/cloudfoundry-incubator/tps/cmd/tps-watcher/main.go:
74: dropsondeDestination = "localhost:3457"

On Fri, Sep 4, 2015 at 3:34 AM, Noburou TANIGUCHI &lt;
dev(a).m001
&gt; wrote:

Hi,
(This is a post in proxy of my collegue.)

There are so many hard-coded dropsonde destinations (actually each of
them
is a metron's listening port) in multiple repositories, while metron's
listening port itself is configurable.

Below is the list that we've found it is hard-coded:



Are they going to be finally configurable in the near future, or is there
any reason to hard-code them?

Thanks in advance.



-----
I'm not a ...
noburou taniguchi
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/So-many-hard-coded-dropsonde-destinations-to-metrons-tp1474.html
Sent from the CF Dev mailing list archive at Nabble.com.




-----
I'm not a ...
noburou taniguchi
--
View this message in context: http://cf-dev.70369.x6.nabble.com/So-many-hard-coded-dropsonde-destinations-to-metrons-tp1474p1518.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Need Help. How to register custom routes to gorouter

Shannon Coen
 

I'll echo the Integration team's question. For what use cases do you want
to register routes directly, rather than through the Cloud Controller API
or cf CLI?

The Routing API Mark mentioned also currently requires a heartbeat.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Fri, Sep 4, 2015 at 1:52 PM, CF Runtime <cfruntime(a)gmail.com> wrote:

Hi Lakshman,

We are wondering why you would like to add routes to the gorouter?
Unfortunately there is not any way to add these untill the routing api
becomes part of the official release. The NATS workaround you are trying to
use requires the route to be published on a heartbeat interval.

Cheers,
CF OSS Release Integration Team

On Fri, Sep 4, 2015 at 7:29 AM, Mark St.Godard <markstgodard(a)gmail.com>
wrote:

The new routing-api and routing-api-cli allow you to register /
unregister routes

You will need to ensure you are also deploying routing-api with cf-release

Routing API
https://github.com/cloudfoundry-incubator/routing-api

Routing API CLI
https://github.com/cloudfoundry-incubator/routing-api-cli

Cheers


On Fri, Sep 4, 2015 at 7:53 AM, James Bayer <jbayer(a)pivotal.io> wrote:

which cf-release are you using?

newer versions support an http api for trusted components to register
routes. shannon is the PM for the routing team and can explain more and
perhaps point to documentation.

note there is an example of mysql registering a route with the previous
approach in a bosh release here:

https://github.com/cloudfoundry/cf-mysql-release/blob/master/jobs/cf-mysql-broker/templates/route-registrar_ctl.erb

On Thu, Sep 3, 2015 at 4:20 PM, Lakshman Mukkamalla (lmukkama) <
lmukkama(a)cisco.com> wrote:

Hi cf devs,
I want to register some custom routes to the gorouter component of
cloud foundry. What I understood was that this could be achieved by
nats-pub command but when I try this command on the gorouter VM it was not
recognized. Can anyone help me how to register custom routes to gorouter.
https://docs.cloudfoundry.org/concepts/architecture/router.html
What worked:
curl -vvv "
http://gorouterusername:gorouterpassword(a)gorouter_ip:gorouter_port/routes
"
This gives me the current routes that are registered.

*What did not work:*
nats-pub 'router.register' 'some custom route'
OR
Is there a rest call to register the custom routes?

It would be of great help if someone can guide me on how to achieve the
similar.

Thanks.


--
Thank you,

James Bayer


Re: can't login with cf CLI but the UAAC tool works

Filip Hanik
 

those urls do not look right. but they are dependent on what url you
deployed the uaa under. ( ie / or /uaa )

what's returned by uaac info is dependent on your uaa config.

I'd have to get back to you in CC config. not my area of expertise. but yes
I believe the CC will have an oauth client registered with the UAA

Filip

On Friday, September 4, 2015, kyle havlovitz <kylehav(a)gmail.com> wrote:

I realize it's a pain, but I'm setting these up without bosh. I'm just
unfamiliar with how the config between the CC and the UAA needs to be set.

The http://localhost:8080/login and http://localhost:8080/uaa seem to be
the correct URLs (they're whats returned by 'uaac info')
Likewise, the CLI seems to be pointed at the right places, it's just
getting this invalid token error, as if the CC can't correctly talk to the
uaa or something.

what should the uaa.resource_id and uaa.symmetric_secret fields in the CC
config be set to if I'm using the default config/clients? Are there any
other values in the CC config that might be the issue here?

On Fri, Sep 4, 2015 at 6:26 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','fhanik(a)pivotal.io');>> wrote:

ok, is that the correct URL?

you're attempting to configure a very large eco system by hand. That can
be a bit difficult. If you want a local cloud foundry, I would suggest
bosh-lite

basically, clone cloudfoundry/cf-release and cloudfoundry/bosh-lite

cd bosh-lite
vagrant up (this launches a VM with bosh director on it)
bin/add-route (sets up network routing)
bin/provision-cf (builds and publishing cloud foundry to the VM

cf api api.10.244.0.34.xip.io
cf login







On Fri, Sep 4, 2015 at 4:18 PM, kyle havlovitz <kylehav(a)gmail.com
<javascript:_e(%7B%7D,'cvml','kylehav(a)gmail.com');>> wrote:

The cloud controller logs have "Invalid bearer token:
#<CF::UAA::InvalidSignature: Signature verification failed>" and the 401
invalid auth message.

On Fri, Sep 4, 2015 at 6:14 PM, kyle havlovitz <kylehav(a)gmail.com
<javascript:_e(%7B%7D,'cvml','kylehav(a)gmail.com');>> wrote:

Ok, I set those 2 properties to http://localhost:8080 and it looks
identical; same error, same endpoints requested.
Could something be wrong with the cloud controller config?

On Fri, Sep 4, 2015 at 5:58 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','fhanik(a)pivotal.io');>> wrote:

yes, this is the URL misconfiguration I was talking about.

In your uaa.yml you should have two properties

login.url: http://localhost:8080
uaa.url: http://localhost:8080

set those two, and let's see that trace again



On Fri, Sep 4, 2015 at 2:58 PM, kyle havlovitz <kylehav(a)gmail.com
<javascript:_e(%7B%7D,'cvml','kylehav(a)gmail.com');>> wrote:

The CLI seems to be able to get a token now though, it's failing for
a different reason:

cf login
API endpoint: http://localhost:8181
REQUEST: [2015-09-04T20:46:51Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: d44503ef-3b2c-4340-9958-ad91daf3706c
{"name":"vcap","build":"2222","support":"
http://support.local.example.com","version":2,"description":"CF v2
test environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API
endpoints are recommended

REQUEST: [2015-09-04T20:46:51Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:51 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA
HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.read scim.userids
cloud_controller.admin scim.write cloud_controller.write password.write
openid cloud_controller.read","jti":"cbda4e10-cf04-4696-a560-2e1f4d2c610c"}
0

OK

REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: b7658709-8145-4e31-a7ed-12a7831e99da
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}

REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux

grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJlNzFmOTNmZS0yMmEyLTQ3ZjgtODgwNC0xN2ZmNmU1YzM1NmMiLCJzdWIiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJzY29wZSI6WyJzY2ltLnJlYWQiLCJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2NvbnRyb2xsZXIucmVhZCJdLCJpYXQiOjE0NDEzOTk2MTgsImV4cCI6MTQ0Mzk5MTYxOCwiY2lkIjoiY2YiLCJjbGllbnRfaWQiOiJjZiIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJhZG1pbiIsInVzZXJfaWQiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJyZXZfc2lnIjoiOTAyODliNjgiLCJhdWQiOlsiY2YiLCJzY2ltIiwiY2xvdWRfY29udHJvbGxlciIsInBhc3N3b3JkIiwib3BlbmlkIl19.-eGB2RWZfYVZkTSvT7c4lUzsY5QZMWgXFHMGGx4HEN8&scope=
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.userids scim.read
cloud_controller.admin password.write scim.write openid
cloud_controller.write
cloud_controller.read","jti":"e62d3265-9ab7-441e-b2b2-69ca92d81d7c"}
0


REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 7b07e39c-60f0-4db4-9274-6a59e23b8f29
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token

API endpoint: http://localhost:8181 (API version: 2.34.0)
User: admin
No org or space targeted, use 'cf target -o ORG -s SPACE'


On Fri, Sep 4, 2015 at 4:49 PM, kyle havlovitz <kylehav(a)gmail.com
<javascript:_e(%7B%7D,'cvml','kylehav(a)gmail.com');>> wrote:

Ok, thanks for the helpful links.
I replaced my config with the uaa.yml and login.yml from there and
now the uaac commands from above work and I can run 'uaac token
owner get'. I still can't login to cf with the cli though.

On Fri, Sep 4, 2015 at 4:15 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','fhanik(a)pivotal.io');>> wrote:

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)

https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may
become a bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com
<javascript:_e(%7B%7D,'cvml','kylehav(a)gmail.com');>> wrote:

is there an example somewhere of a minimalist working config for
them? I'm going through at the moment and trying to make mine resemble the
config here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','fhanik(a)pivotal.io');>> wrote:

ok, that tells me that your configuration of the UAA clients is
incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com
<javascript:_e(%7B%7D,'cvml','kylehav(a)gmail.com');>> wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','fhanik(a)pivotal.io');>> wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <
kylehav(a)gmail.com
<javascript:_e(%7B%7D,'cvml','kylehav(a)gmail.com');>> wrote:

I started the uaa by building from the tagged version in
cf-release v215 and running it via tomcat with a custom config file, but I
didn't specify a database. I have both a cf and admin section in the uaa
clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io
<javascript:_e(%7B%7D,'cvml','fhanik(a)pivotal.io');>> wrote:

ok, so the URL you have is /oauth/token, that's fine. your
trace returns

"authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we
can fix that later.

How did you start the UAA? Are you sure that your UAA has a
client named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <
kylehav(a)gmail.com
<javascript:_e(%7B%7D,'cvml','kylehav(a)gmail.com');>> wrote:

Running that command against /uaa/oauth/token gives just a
redirect to /login. Doing it with /oauth/token gives a 401 unauthorized,
same as the cf cli.

What do you mean by deploy it as root "/"? As in, a override
the url it hosts the endpoints at?


Re: can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 

I realize it's a pain, but I'm setting these up without bosh. I'm just
unfamiliar with how the config between the CC and the UAA needs to be set.

The http://localhost:8080/login and http://localhost:8080/uaa seem to be
the correct URLs (they're whats returned by 'uaac info')
Likewise, the CLI seems to be pointed at the right places, it's just
getting this invalid token error, as if the CC can't correctly talk to the
uaa or something.

what should the uaa.resource_id and uaa.symmetric_secret fields in the CC
config be set to if I'm using the default config/clients? Are there any
other values in the CC config that might be the issue here?

On Fri, Sep 4, 2015 at 6:26 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, is that the correct URL?

you're attempting to configure a very large eco system by hand. That can
be a bit difficult. If you want a local cloud foundry, I would suggest
bosh-lite

basically, clone cloudfoundry/cf-release and cloudfoundry/bosh-lite

cd bosh-lite
vagrant up (this launches a VM with bosh director on it)
bin/add-route (sets up network routing)
bin/provision-cf (builds and publishing cloud foundry to the VM

cf api api.10.244.0.34.xip.io
cf login







On Fri, Sep 4, 2015 at 4:18 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

The cloud controller logs have "Invalid bearer token:
#<CF::UAA::InvalidSignature: Signature verification failed>" and the 401
invalid auth message.

On Fri, Sep 4, 2015 at 6:14 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Ok, I set those 2 properties to http://localhost:8080 and it looks
identical; same error, same endpoints requested.
Could something be wrong with the cloud controller config?

On Fri, Sep 4, 2015 at 5:58 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, this is the URL misconfiguration I was talking about.

In your uaa.yml you should have two properties

login.url: http://localhost:8080
uaa.url: http://localhost:8080

set those two, and let's see that trace again



On Fri, Sep 4, 2015 at 2:58 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

The CLI seems to be able to get a token now though, it's failing for a
different reason:

cf login
API endpoint: http://localhost:8181
REQUEST: [2015-09-04T20:46:51Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: d44503ef-3b2c-4340-9958-ad91daf3706c
{"name":"vcap","build":"2222","support":"
http://support.local.example.com","version":2,"description":"CF v2
test environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API
endpoints are recommended

REQUEST: [2015-09-04T20:46:51Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:51 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA
HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.read scim.userids
cloud_controller.admin scim.write cloud_controller.write password.write
openid cloud_controller.read","jti":"cbda4e10-cf04-4696-a560-2e1f4d2c610c"}
0

OK

REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: b7658709-8145-4e31-a7ed-12a7831e99da
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}

REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux

grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJlNzFmOTNmZS0yMmEyLTQ3ZjgtODgwNC0xN2ZmNmU1YzM1NmMiLCJzdWIiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJzY29wZSI6WyJzY2ltLnJlYWQiLCJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2NvbnRyb2xsZXIucmVhZCJdLCJpYXQiOjE0NDEzOTk2MTgsImV4cCI6MTQ0Mzk5MTYxOCwiY2lkIjoiY2YiLCJjbGllbnRfaWQiOiJjZiIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJhZG1pbiIsInVzZXJfaWQiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJyZXZfc2lnIjoiOTAyODliNjgiLCJhdWQiOlsiY2YiLCJzY2ltIiwiY2xvdWRfY29udHJvbGxlciIsInBhc3N3b3JkIiwib3BlbmlkIl19.-eGB2RWZfYVZkTSvT7c4lUzsY5QZMWgXFHMGGx4HEN8&scope=
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.userids scim.read
cloud_controller.admin password.write scim.write openid
cloud_controller.write
cloud_controller.read","jti":"e62d3265-9ab7-441e-b2b2-69ca92d81d7c"}
0


REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 7b07e39c-60f0-4db4-9274-6a59e23b8f29
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token

API endpoint: http://localhost:8181 (API version: 2.34.0)
User: admin
No org or space targeted, use 'cf target -o ORG -s SPACE'


On Fri, Sep 4, 2015 at 4:49 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Ok, thanks for the helpful links.
I replaced my config with the uaa.yml and login.yml from there and
now the uaac commands from above work and I can run 'uaac token
owner get'. I still can't login to cf with the cli though.

On Fri, Sep 4, 2015 at 4:15 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)

https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may
become a bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

is there an example somewhere of a minimalist working config for
them? I'm going through at the moment and trying to make mine resemble the
config here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, that tells me that your configuration of the UAA clients is
incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <
kylehav(a)gmail.com> wrote:

I started the uaa by building from the tagged version in
cf-release v215 and running it via tomcat with a custom config file, but I
didn't specify a database. I have both a cf and admin section in the uaa
clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so the URL you have is /oauth/token, that's fine. your
trace returns

"authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we
can fix that later.

How did you start the UAA? Are you sure that your UAA has a
client named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <
kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a
redirect to /login. Doing it with /oauth/token gives a 401 unauthorized,
same as the cf cli.

What do you mean by deploy it as root "/"? As in, a override
the url it hosts the endpoints at?


Re: can't login with cf CLI but the UAAC tool works

Filip Hanik
 

ok, is that the correct URL?

you're attempting to configure a very large eco system by hand. That can be
a bit difficult. If you want a local cloud foundry, I would suggest
bosh-lite

basically, clone cloudfoundry/cf-release and cloudfoundry/bosh-lite

cd bosh-lite
vagrant up (this launches a VM with bosh director on it)
bin/add-route (sets up network routing)
bin/provision-cf (builds and publishing cloud foundry to the VM

cf api api.10.244.0.34.xip.io
cf login

On Fri, Sep 4, 2015 at 4:18 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

The cloud controller logs have "Invalid bearer token:
#<CF::UAA::InvalidSignature: Signature verification failed>" and the 401
invalid auth message.

On Fri, Sep 4, 2015 at 6:14 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Ok, I set those 2 properties to http://localhost:8080 and it looks
identical; same error, same endpoints requested.
Could something be wrong with the cloud controller config?

On Fri, Sep 4, 2015 at 5:58 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, this is the URL misconfiguration I was talking about.

In your uaa.yml you should have two properties

login.url: http://localhost:8080
uaa.url: http://localhost:8080

set those two, and let's see that trace again



On Fri, Sep 4, 2015 at 2:58 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

The CLI seems to be able to get a token now though, it's failing for a
different reason:

cf login
API endpoint: http://localhost:8181
REQUEST: [2015-09-04T20:46:51Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: d44503ef-3b2c-4340-9958-ad91daf3706c
{"name":"vcap","build":"2222","support":"
http://support.local.example.com","version":2,"description":"CF v2
test environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API
endpoints are recommended

REQUEST: [2015-09-04T20:46:51Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:51 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.read scim.userids
cloud_controller.admin scim.write cloud_controller.write password.write
openid cloud_controller.read","jti":"cbda4e10-cf04-4696-a560-2e1f4d2c610c"}
0

OK

REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: b7658709-8145-4e31-a7ed-12a7831e99da
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}

REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux

grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJlNzFmOTNmZS0yMmEyLTQ3ZjgtODgwNC0xN2ZmNmU1YzM1NmMiLCJzdWIiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJzY29wZSI6WyJzY2ltLnJlYWQiLCJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2NvbnRyb2xsZXIucmVhZCJdLCJpYXQiOjE0NDEzOTk2MTgsImV4cCI6MTQ0Mzk5MTYxOCwiY2lkIjoiY2YiLCJjbGllbnRfaWQiOiJjZiIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJhZG1pbiIsInVzZXJfaWQiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJyZXZfc2lnIjoiOTAyODliNjgiLCJhdWQiOlsiY2YiLCJzY2ltIiwiY2xvdWRfY29udHJvbGxlciIsInBhc3N3b3JkIiwib3BlbmlkIl19.-eGB2RWZfYVZkTSvT7c4lUzsY5QZMWgXFHMGGx4HEN8&scope=
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.userids scim.read
cloud_controller.admin password.write scim.write openid
cloud_controller.write
cloud_controller.read","jti":"e62d3265-9ab7-441e-b2b2-69ca92d81d7c"}
0


REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 7b07e39c-60f0-4db4-9274-6a59e23b8f29
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token

API endpoint: http://localhost:8181 (API version: 2.34.0)
User: admin
No org or space targeted, use 'cf target -o ORG -s SPACE'


On Fri, Sep 4, 2015 at 4:49 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Ok, thanks for the helpful links.
I replaced my config with the uaa.yml and login.yml from there and now
the uaac commands from above work and I can run 'uaac token owner
get'. I still can't login to cf with the cli though.

On Fri, Sep 4, 2015 at 4:15 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)
https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may become
a bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

is there an example somewhere of a minimalist working config for
them? I'm going through at the moment and trying to make mine resemble the
config here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, that tells me that your configuration of the UAA clients is
incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com
wrote:
I started the uaa by building from the tagged version in
cf-release v215 and running it via tomcat with a custom config file, but I
didn't specify a database. I have both a cf and admin section in the uaa
clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so the URL you have is /oauth/token, that's fine. your
trace returns

"authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we
can fix that later.

How did you start the UAA? Are you sure that your UAA has a
client named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <
kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a
redirect to /login. Doing it with /oauth/token gives a 401 unauthorized,
same as the cf cli.

What do you mean by deploy it as root "/"? As in, a override
the url it hosts the endpoints at?


Re: can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 

The cloud controller logs have "Invalid bearer token:
#<CF::UAA::InvalidSignature: Signature verification failed>" and the 401
invalid auth message.

On Fri, Sep 4, 2015 at 6:14 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Ok, I set those 2 properties to http://localhost:8080 and it looks
identical; same error, same endpoints requested.
Could something be wrong with the cloud controller config?

On Fri, Sep 4, 2015 at 5:58 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, this is the URL misconfiguration I was talking about.

In your uaa.yml you should have two properties

login.url: http://localhost:8080
uaa.url: http://localhost:8080

set those two, and let's see that trace again



On Fri, Sep 4, 2015 at 2:58 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

The CLI seems to be able to get a token now though, it's failing for a
different reason:

cf login
API endpoint: http://localhost:8181
REQUEST: [2015-09-04T20:46:51Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: d44503ef-3b2c-4340-9958-ad91daf3706c
{"name":"vcap","build":"2222","support":"
http://support.local.example.com","version":2,"description":"CF v2 test
environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API endpoints
are recommended

REQUEST: [2015-09-04T20:46:51Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:51 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.read scim.userids
cloud_controller.admin scim.write cloud_controller.write password.write
openid cloud_controller.read","jti":"cbda4e10-cf04-4696-a560-2e1f4d2c610c"}
0

OK

REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: b7658709-8145-4e31-a7ed-12a7831e99da
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}

REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux

grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJlNzFmOTNmZS0yMmEyLTQ3ZjgtODgwNC0xN2ZmNmU1YzM1NmMiLCJzdWIiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJzY29wZSI6WyJzY2ltLnJlYWQiLCJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2NvbnRyb2xsZXIucmVhZCJdLCJpYXQiOjE0NDEzOTk2MTgsImV4cCI6MTQ0Mzk5MTYxOCwiY2lkIjoiY2YiLCJjbGllbnRfaWQiOiJjZiIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJhZG1pbiIsInVzZXJfaWQiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJyZXZfc2lnIjoiOTAyODliNjgiLCJhdWQiOlsiY2YiLCJzY2ltIiwiY2xvdWRfY29udHJvbGxlciIsInBhc3N3b3JkIiwib3BlbmlkIl19.-eGB2RWZfYVZkTSvT7c4lUzsY5QZMWgXFHMGGx4HEN8&scope=
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.userids scim.read
cloud_controller.admin password.write scim.write openid
cloud_controller.write
cloud_controller.read","jti":"e62d3265-9ab7-441e-b2b2-69ca92d81d7c"}
0


REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 7b07e39c-60f0-4db4-9274-6a59e23b8f29
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token

API endpoint: http://localhost:8181 (API version: 2.34.0)
User: admin
No org or space targeted, use 'cf target -o ORG -s SPACE'


On Fri, Sep 4, 2015 at 4:49 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Ok, thanks for the helpful links.
I replaced my config with the uaa.yml and login.yml from there and now
the uaac commands from above work and I can run 'uaac token owner
get'. I still can't login to cf with the cli though.

On Fri, Sep 4, 2015 at 4:15 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)
https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may become
a bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

is there an example somewhere of a minimalist working config for
them? I'm going through at the moment and trying to make mine resemble the
config here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, that tells me that your configuration of the UAA clients is
incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in
cf-release v215 and running it via tomcat with a custom config file, but I
didn't specify a database. I have both a cf and admin section in the uaa
clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we
can fix that later.

How did you start the UAA? Are you sure that your UAA has a
client named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <
kylehav(a)gmail.com> wrote:

Running that command against /uaa/oauth/token gives just a
redirect to /login. Doing it with /oauth/token gives a 401 unauthorized,
same as the cf cli.

What do you mean by deploy it as root "/"? As in, a override
the url it hosts the endpoints at?


Re: can't login with cf CLI but the UAAC tool works

kyle havlovitz <kylehav@...>
 

Ok, I set those 2 properties to http://localhost:8080 and it looks
identical; same error, same endpoints requested.
Could something be wrong with the cloud controller config?

On Fri, Sep 4, 2015 at 5:58 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

yes, this is the URL misconfiguration I was talking about.

In your uaa.yml you should have two properties

login.url: http://localhost:8080
uaa.url: http://localhost:8080

set those two, and let's see that trace again



On Fri, Sep 4, 2015 at 2:58 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

The CLI seems to be able to get a token now though, it's failing for a
different reason:

cf login
API endpoint: http://localhost:8181
REQUEST: [2015-09-04T20:46:51Z]
GET /v2/info HTTP/1.1
Host: localhost:8181
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Content-Length: 406
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: d44503ef-3b2c-4340-9958-ad91daf3706c
{"name":"vcap","build":"2222","support":"http://support.local.example.com","version":2,"description":"CF
v2 test environment","authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa
","min_cli_version":null,"min_recommended_cli_version":null,"api_version":"2.34.0","app_ssh_endpoint":null,"app_ssh_host_key_fingerprint":null,"logging_endpoint":"ws://
127.0.0.1:9090"}
Warning: Insecure http API endpoint detected: secure https API endpoints
are recommended

REQUEST: [2015-09-04T20:46:51Z]
GET /login HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:51Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-cache, no-store, max-age=0
Content-Language: en-US
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:51 GMT
Expires: 0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
1fd

{"timestamp":"2015-08-05T00:00:41+0000","app":{"version":"2.5.1"},"idpDefinitions":[],"fieldUsernameShow":true,"zone_name":"uaa","commit_id":"eae6724","prompts":{"username":["text","Email"],"password":["password","Password"]},"forgotPasswordLink":"/forgot_password","createAccountLink":"/create_account","links":{"register":"/create_account","passwd":"/forgot_password","login":"
http://localhost:8080/login","uaa":"http://localhost:8080/uaa
"},"entityID":"cloudfoundry-saml-login","linkCreateAccountShow":true}
0


Email> admin
Password>
Authenticating...
REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux
grant_type=password&password=[PRIVATE DATA HIDDEN]&scope=&username=admin
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.read scim.userids
cloud_controller.admin scim.write cloud_controller.write password.write
openid cloud_controller.read","jti":"cbda4e10-cf04-4696-a560-2e1f4d2c610c"}
0

OK

REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: b7658709-8145-4e31-a7ed-12a7831e99da
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}

REQUEST: [2015-09-04T20:46:58Z]
POST /oauth/token HTTP/1.1
Host: localhost:8080
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.12.3-c0c9a03 / linux

grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJlNzFmOTNmZS0yMmEyLTQ3ZjgtODgwNC0xN2ZmNmU1YzM1NmMiLCJzdWIiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJzY29wZSI6WyJzY2ltLnJlYWQiLCJzY2ltLnVzZXJpZHMiLCJjbG91ZF9jb250cm9sbGVyLmFkbWluIiwic2NpbS53cml0ZSIsImNsb3VkX2NvbnRyb2xsZXIud3JpdGUiLCJwYXNzd29yZC53cml0ZSIsIm9wZW5pZCIsImNsb3VkX2NvbnRyb2xsZXIucmVhZCJdLCJpYXQiOjE0NDEzOTk2MTgsImV4cCI6MTQ0Mzk5MTYxOCwiY2lkIjoiY2YiLCJjbGllbnRfaWQiOiJjZiIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91YWEvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJhZG1pbiIsInVzZXJfaWQiOiIzMDBkZTc1YS1mN2RhLTRjMWQtYjA0Yi02YWZhZjI1ZmE5MjgiLCJyZXZfc2lnIjoiOTAyODliNjgiLCJhdWQiOlsiY2YiLCJzY2ltIiwiY2xvdWRfY29udHJvbGxlciIsInBhc3N3b3JkIiwib3BlbmlkIl19.-eGB2RWZfYVZkTSvT7c4lUzsY5QZMWgXFHMGGx4HEN8&scope=
RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Cache-Control: no-store
Content-Type: application/json;charset=UTF-8
Date: Fri, 04 Sep 2015 20:46:58 GMT
Expires: 0
Pragma: no-cache
Pragma: no-cache
Server: Apache-Coyote/1.1
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
738
{"access_token":"[PRIVATE DATA
HIDDEN]","token_type":"bearer","refresh_token":"[PRIVATE DATA
HIDDEN]","expires_in":43199,"scope":"scim.userids scim.read
cloud_controller.admin password.write scim.write openid
cloud_controller.write
cloud_controller.read","jti":"e62d3265-9ab7-441e-b2b2-69ca92d81d7c"}
0


REQUEST: [2015-09-04T20:46:58Z]
GET /v2/organizations HTTP/1.1
Host: localhost:8181
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.12.3-c0c9a03 / linux


RESPONSE: [2015-09-04T20:46:58Z]
HTTP/1.1 401 Unauthorized
Content-Length: 97
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Server: thin
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 7b07e39c-60f0-4db4-9274-6a59e23b8f29
{
"code": 1000,
"description": "Invalid Auth Token",
"error_code": "CF-InvalidAuthToken"
}
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token
FAILED
Error finding available orgs
Invalid auth token: Invalid Auth Token

API endpoint: http://localhost:8181 (API version: 2.34.0)
User: admin
No org or space targeted, use 'cf target -o ORG -s SPACE'


On Fri, Sep 4, 2015 at 4:49 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Ok, thanks for the helpful links.
I replaced my config with the uaa.yml and login.yml from there and now
the uaac commands from above work and I can run 'uaac token owner get'.
I still can't login to cf with the cli though.

On Fri, Sep 4, 2015 at 4:15 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

Minimalist defaults are in the UAA repo (uaa.yml and login.yml)
https://github.com/cloudfoundry/uaa/tree/master/uaa/src/main/resources

Yaml is very sensitive to indentation. So hand crafting it may become a
bit difficult.

If you want the UAA to provide all default values (including
admin/adminsecret client and cf/<blank password> client, then don't add any
uaa.yml config file at all. Just start up UAA with it's defaults.
It will suck in client defaults from

https://github.com/cloudfoundry/uaa/blob/feature/invitations_flow_by_email_domain/uaa/src/main/webapp/WEB-INF/spring/oauth-clients.xml#L47-L172

Filip


On Fri, Sep 4, 2015 at 2:05 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

is there an example somewhere of a minimalist working config for them?
I'm going through at the moment and trying to make mine resemble the config
here:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/uaa/templates/uaa.yml.erb

I'm also defining a test admin user in the scim users section

On Fri, Sep 4, 2015 at 4:00 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:

ok, that tells me that your configuration of the UAA clients is
incorrect



On Fri, Sep 4, 2015 at 1:44 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

ok so the 'uaac token client get' fails, and the error is 'Bad
credentials'

On Fri, Sep 4, 2015 at 3:33 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so we can validate that

uaac target http://localhost:8080
uaac token client get admin -s <your admin client secret>
uaac clients

Should show your 'cf' client in the list

then we can do

uaac token owner get cf <username> -s "" -p <user password>

and if that works, we can take it to the next step



On Fri, Sep 4, 2015 at 1:26 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

I started the uaa by building from the tagged version in
cf-release v215 and running it via tomcat with a custom config file, but I
didn't specify a database. I have both a cf and admin section in the uaa
clients config:

cf:

id: cf
override: true
authorized-grant-types: password,implicit,refresh_token
authorities: uaa.none
scope:
cloud_controller.read,cloud_controller.write,openid,password.write,cloud_controller.admin,scim.read,scim.write
secret: 'xxxxxxxxxx'

admin:

id: admin
authorized-grant-types: client_credentials
authorities:
clients.read,clients.write,clients.secret,password.write,scim.read,uaa.admin
scope: read,write,password
resource-ids: clients
secret: 'xxxxxxxxxx'


On Fri, Sep 4, 2015 at 3:09 PM, Filip Hanik <fhanik(a)pivotal.io>
wrote:

ok, so the URL you have is /oauth/token, that's fine. your trace
returns

"authorization_endpoint":"http://localhost:8080
","token_endpoint":"http://localhost:8080/uaa"

indicating that there is a misconfiguration somewhere, but we can
fix that later.

How did you start the UAA? Are you sure that your UAA has a
client named 'cf' in its database?



On Fri, Sep 4, 2015 at 1:05 PM, kyle havlovitz <kylehav(a)gmail.com
wrote:
Running that command against /uaa/oauth/token gives just a
redirect to /login. Doing it with /oauth/token gives a 401 unauthorized,
same as the cf cli.

What do you mean by deploy it as root "/"? As in, a override the
url it hosts the endpoints at?

7881 - 7900 of 9426