|
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@...>
|
|
|
Re: Application only starts when a bogus service is attached
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#7a538fbThere 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?
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
|
|
|
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 < jbayer@ > 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 <
jbayer@ > 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 <
cholick@ > 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.htmlSent from the CF Dev mailing list archive at Nabble.com.
|
|
|
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]".
toggle quoted message
Show quoted text
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
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.
toggle quoted message
Show quoted text
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
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 < dev(a).m001 > 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.htmlSent from the CF Dev mailing list archive at Nabble.com.
|
|
|
Re: Need Help. How to register custom routes to gorouter
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.
toggle quoted message
Show quoted text
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
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
toggle quoted message
Show quoted text
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
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
toggle quoted message
Show quoted text
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.
toggle quoted message
Show quoted text
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?
|
|
|
Re: can't login with cf CLI but the UAAC tool works
yes, this is the URL misconfiguration I was talking about. In your uaa.yml you should have two properties login.url: http://localhost:8080uaa.url: http://localhost:8080set 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: Status of support for route paths in cli
Sure. I added a note in the note story to consider that request.
-Dieu
toggle quoted message
Show quoted text
On Fri, Sep 4, 2015 at 2:14 PM, Mike Youngstrom <youngm(a)gmail.com> wrote: One other note to whoever ends up working on this issue. It would be
great to add support in "cf push" and manifest commands as well.
Mike
On Fri, Sep 4, 2015 at 11:27 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:
Great! Thanks Dieu.
Mike
On Fri, Sep 4, 2015 at 10:46 AM, Dieu Cao <dcao(a)pivotal.io> wrote:
Shannon recently pulled the story over into the Routing team's tracker
[1] with the intention to submit a PR for it to the CLI team.
-Dieu
CF CAPI PM
[1] https://www.pivotaltracker.com/story/show/93368928
On Fri, Sep 4, 2015 at 9:09 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:
Route path support has been in the CC and Router for several months
now. What is the status of getting these into the CLI? I did a quick
search for a CLI tracker story and couldn't find one.
Mike
|
|
|
Re: Status of support for route paths in cli
Mike Youngstrom <youngm@...>
One other note to whoever ends up working on this issue. It would be great
to add support in "cf push" and manifest commands as well.
Mike
toggle quoted message
Show quoted text
On Fri, Sep 4, 2015 at 11:27 AM, Mike Youngstrom <youngm(a)gmail.com> wrote: Great! Thanks Dieu.
Mike
On Fri, Sep 4, 2015 at 10:46 AM, Dieu Cao <dcao(a)pivotal.io> wrote:
Shannon recently pulled the story over into the Routing team's tracker
[1] with the intention to submit a PR for it to the CLI team.
-Dieu
CF CAPI PM
[1] https://www.pivotaltracker.com/story/show/93368928
On Fri, Sep 4, 2015 at 9:09 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:
Route path support has been in the CC and Router for several months
now. What is the status of getting these into the CLI? I did a quick
search for a CLI tracker story and couldn't find one.
Mike
|
|
|
Re: can't login with cf CLI but the UAAC tool works
kyle havlovitz <kylehav@...>
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:8181REQUEST: [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: Need Help. How to register custom routes to gorouter
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
|
|
|
