|
UAA - Non-Browser Requests Code: GET /oauth/authorize, and sample login application
Yogesh Sajanikar
I have setup uaa service, and trying to setup a non-browser client (another server actually) to get the authorization. In fact, I am trying to adapt sample "login" application to my needs.
However, the step mentioned in documentation to login fails with "403". Here is the curl command that I am trying. curl -v -H "Accept:application/json" http://localhost:8080/uaa/login.do -d "username=marissa&password=koala" --cookie cookies.txt --cookie-jar cookies.txt And here is the response that I get. * Trying ::1... * Connected to localhost (::1) port 8080 (#0) POST /uaa/login.do HTTP/1.1* upload completely sent off: 31 out of 31 bytes < HTTP/1.1 403 Forbidden < Server: Apache-Coyote/1.1 < Strict-Transport-Security: max-age=31536000 < Cache-Control: no-cache, no-store, max-age=0, must-revalidate < Pragma: no-cache < Expires: 0 < X-XSS-Protection: 1; mode=block < X-Frame-Options: DENY < X-Content-Type-Options: nosniff < Cache-Control: no-store < Content-Type: application/json;charset=UTF-8 < Content-Language: en-US < Transfer-Encoding: chunked < Date: Thu, 04 Feb 2016 04:30:43 GMT < * Connection #0 to host localhost left intact {"app":{"version":"3.0.1"},"links":{"uaa":"http://localhost:8080/uaa","passwd":"/forgot_password","login":"http://localhost:8080/uaa","register":"/create_account"},"zone_name":"uaa","entityID":"cloudfoundry-saml-login","commit_id":"4f37e9b","idpDefinitions":{},"prompts":{"username":["text","Email"],"password":["password","Password"]},"timestamp":"2016-01-26T01:13:19+0530"} The sample application "login" does not work in a similar way!
|
|
|
|
Re: Upgrading consul-release to consul 0.6.0
Amit Kumar Gupta
Hi Gwenn
Thanks for your feedback, and taking the time to look through the changelog! cf-release/consul-release have been on 0.5.2 (post BoltDB migration) since Jun 2015: https://github.com/cloudfoundry/cf-release/commit/1683884704c91ec1609efe3c8390c058ccc6c537. So there should be no concerns around any migrations from LMDB. Best, Amit On Wed, Feb 3, 2016 at 6:04 PM, Gwenn Etourneau <getourneau(a)pivotal.io> wrote: My biggest concern is the Data migration from LMDB to BoltDB, I know there
|
|
|
|
Re: Routes limitation per app
Siva Balan <mailsiva@...>
Thanks Filip and Shawn. I think Filip's suggestion would solve our problem.
toggle quoted messageShow quoted text
On Wed, Feb 3, 2016 at 2:02 PM, Shawn Nielsen <sknielse(a)gmail.com> wrote:
The only known route limitation I am aware of on a CF org is the route
|
|
|
|
Re: Upgrading consul-release to consul 0.6.0
Gwenn Etourneau
My biggest concern is the Data migration from LMDB to BoltDB, I know there
toggle quoted messageShow quoted text
is a CLI to do that but I am concern about the migration of the DATA itself. *" Previously, Consul would automatically detect data directories using the old LMDB format, and convert them to the newer BoltDB format. This automatic upgrade has been removed for Consul 0.6, and instead a safeguard has been put in place which will prevent Consul from booting if the old directory format is detected. "* *AND* * Consul should be provisioned with physical memory approximately 2X the data set size to allow for bursty allocations and subsequent garbage collection.*
On Thu, Feb 4, 2016 at 3:28 AM, Amit Gupta <agupta(a)pivotal.io> wrote:
Hi cf-dev, cf-diego
|
|
|
|
Re: Support for HTTP/2
Shannon Coen
Thank you for the additional context, Carlo. I agree the loss of support
for non-TLS requests would not only restrictive, but potentially backwards incompatible. Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Tue, Feb 2, 2016 at 9:05 PM, Carlo Alberto Ferraris < carlo.ferraris(a)rakuten.com> wrote: With this limitation in mind, an upstream component could still terminateJust as a small followup, consider that companies might have internal
|
|
|
|
Re: Routes limitation per app
Shawn Nielsen
The only known route limitation I am aware of on a CF org is the route
toggle quoted messageShow quoted text
quota associated with the org. If you type 'cf org [ORG_NAME]' you should see how many routes are allowed. You can also view quotas directly using 'cf quotas'. We're running thousands of routes and haven't seen an issue as long as the route quota is set high enough.
On Wed, Feb 3, 2016 at 11:40 AM, Filip Hanik <fhanik(a)pivotal.io> wrote:
hi Siva,
|
|
|
|
Re: bits-service fog usage question
Tim Lawrence <tim.lawrence1984@...>
We would potentially be affected as we use Fog's Atmos provider for now. In the future we plan to implement fully s3 compatible
toggle quoted messageShow quoted text
Object storage so no problem then but may require some backwards compatibility for a while.. Tim Sent from my iPhone
On 3 Feb 2016, at 14:21, Tammer Saleh <tsaleh(a)pivotal.io> wrote:
|
|
|
|
Re: Routes limitation per app
Filip Hanik
hi Siva,
toggle quoted messageShow quoted text
can't you just register *.uaa.test.com as a route? https://github.com/cloudfoundry/cf-release/blob/master/templates/cf-jobs.yml#L173-L182
On Wed, Feb 3, 2016 at 10:05 AM, Siva Balan <mailsiva(a)gmail.com> wrote:
Hello,
|
|
|
|
Requirements introduced in cf-release v229 for external PostgreSQL as CCDB
Shannon Coen
In support of work in progress to enable developers to specify application
ports when mapping routes, cf-release v229 introduces a database migration for CCDB. *For deployments that use a PostgreSQL database for CCDB that is NOT the PostreSQL job that comes with cf-release*, v229 introduces the following requirements. These requirements are applicable for subsequent releases. If you are using the PostgreSQL job that comes with cf-release, or if you are using MySQL as the backing db for CC, no action is necessary. - PostgreSQL 9.1 is required at a minimum - For versions 9.1-9.3, operators must first install the extension uuid-ossp [1] - For versions 9.4 and newer, operators must first install the extension pgcrypto [2] Release Notes have been updated. [3] [1] http://www.postgresql.org/docs/9.1/static/uuid-ossp.html [2] http://www.postgresql.org/docs/9.4/static/pgcrypto.html [3] https://github.com/cloudfoundry/cf-release/releases/tag/v229 Thank you, Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc.
|
|
|
|
Upgrading consul-release to consul 0.6.0
Amit Kumar Gupta
Hi cf-dev, cf-diego
The CF Infrastructure team which maintains consul-release ( https://github.com/cloudfoundry-incubator/consul-release) is considering bumping from consul 0.5.2 to 0.6.0. There are many changes between those consecutive releases, which you can read about here: * 0.6.0: https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#060-december-3-2015 * 0.6.1: https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#061-january-6-2016 * 0.6.2: https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#062-january-13-2016 We would like to explore this bump to get the change in 0.6.0 where consul moved to a pure Go implementation, allowing us to avoid having to set GOMAXPROCS when starting the consul server, and then some of the security fixes in 0.6.2 for good measure. This change would also affect clients of the consul server in consul-release, hopefully in mainly positive ways. If you're a consumer of consul-release as a client, I would appreciate your feedback on this potential bump to consul in consul-release. Thanks, Amit, CF Infrastructure team PM
|
|
|
|
Re: Issue with crashing Windows apps on Diego
Aaron Huber
Yes, I agree that setting the specific URI to check would be necessary as
well so that developers could avoid some of the other concerns. So the ones I can think of: * URI / endpoint * Expected status codes - this would probably need to be a range or an array, or even an array of ranges :-) * Timeout Aaron -- View this message in context: http://cf-dev.70369.x6.nabble.com/Issue-with-crashing-Windows-apps-on-Diego-tp3586p3662.html Sent from the CF Dev mailing list archive at Nabble.com.
|
|
|
|
Routes limitation per app
Siva Balan <mailsiva@...>
Hello,
We have an implementation of UAA using Identity zones where each zone in UAA is represented by a unique route and this route is bound to that UAA app in our cloudfoundry implementation. Eg: If UAA is deployed at uaa.test.com, then the routes for the zones are represented as: zone1.uaa.test.com zone2.uaa.test.com zone3.uaa.test.com We have a requirement to test for 10,000 identity zones which translates to 10,000 routes bound to a single UAA app. We would like to know if there are any known limitations to the number of routes that can be created per org or number of routes that can be bound to a single app. Thanks Siva Balan -- http://www.twitter.com/sivabalans
|
|
|
|
Re: bits-service fog usage question
Tammer Saleh
I can't comment on the common use cases, and who this change would break.
toggle quoted messageShow quoted text
However, I'm very much in favor of hiding this implementation detail from our API. Letting a library's internal API leak into our product surface area is a very bad thing for us long term <http://tammersaleh.com/posts/mind-the-map/>. Cheers, Tammer Saleh Senior Director of Engineering, Pivotal CF, London http://pivotal.io | http://tammersaleh.com | +44 7463 939332
On Wed, Feb 3, 2016 at 1:07 PM, Simon D Moser <SMOSER(a)de.ibm.com> wrote:
ps: forgot to mention that openStack Swift is of course in scope, too.
|
|
|
|
Re: bits-service fog usage question
Simon D Moser
ps: forgot to mention that openStack Swift is of course in scope, too.
Mit freundlichen Grüßen / Kind regards Simon Moser Senior Technical Staff Member / IBM Master Inventor Bluemix Application Platform Lead Architect Dept. C727, IBM Research & Development Boeblingen ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Schoenaicher Str. 220 71032 Boeblingen Phone: +49-7031-16-4304 Fax: +49-7031-16-4890 E-Mail: smoser(a)de.ibm.com ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 ** Great minds discuss ideas; average minds discuss events; small minds discuss people. Eleanor Roosevelt From: Simon D Moser/Germany/IBM(a)IBMDE To: "CF Developers Mailing List" <cf-dev(a)lists.cloudfoundry.org> Date: 03/02/2016 11:51 Subject: [cf-dev] bits-service fog usage question Hi everybody, we are beginning work on the Bits Service proposed here [1] for handling all kinds of blobstore related operations - a functionality that is in the cloud controller today. Cloud controller currently uses the ruby gem 'fog' [2] for interactions with the back-end blobstore. We are thinking about removing the dependency on the ruby fog gem and would like to better understand what blobstores and configurations you, in the community, are using today. Unfortunately, the fact that this gem is used leaks out to the cc configuration [3] by taking an opaque fog hash, and therefore it could potentially be used in many ways. We would like to get feedback on whether it would be fine if the new bits service only supported s3 compatible blobstores, externally provided nfs, and webdav (and no longer everything that fog potentially supports). Would you be impacted by such a decision, and how? What connection parameters/features of fog do you currently make use of? [1] https://docs.google.com/document/d/1kIjBuJJ0ZiJRPzMJW8dtce26jhAHbK7KotY9416YMEI/edit?usp=sharing [2] https://github.com/fog/fog [3] https://github.com/cloudfoundry/cf-release/blob/master/jobs/cloud_controller_ng/spec#L250-L251 Mit freundlichen Grüßen / Kind regards Simon Moser Senior Technical Staff Member / IBM Master Inventor Bluemix Application Platform Lead Architect Dept. C727, IBM Research & Development Boeblingen ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Schoenaicher Str. 220 71032 Boeblingen Phone: +49-7031-16-4304 Fax: +49-7031-16-4890 E-Mail: smoser(a)de.ibm.com ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 ** Great minds discuss ideas; average minds discuss events; small minds discuss people. Eleanor Roosevelt
|
|
|
|
bits-service fog usage question
Simon D Moser
Hi everybody,
we are beginning work on the Bits Service proposed here [1] for handling all kinds of blobstore related operations - a functionality that is in the cloud controller today. Cloud controller currently uses the ruby gem 'fog' [2] for interactions with the back-end blobstore. We are thinking about removing the dependency on the ruby fog gem and would like to better understand what blobstores and configurations you, in the community, are using today. Unfortunately, the fact that this gem is used leaks out to the cc configuration [3] by taking an opaque fog hash, and therefore it could potentially be used in many ways. We would like to get feedback on whether it would be fine if the new bits service only supported s3 compatible blobstores, externally provided nfs, and webdav (and no longer everything that fog potentially supports). Would you be impacted by such a decision, and how? What connection parameters/features of fog do you currently make use of? [1] https://docs.google.com/document/d/1kIjBuJJ0ZiJRPzMJW8dtce26jhAHbK7KotY9416YMEI/edit?usp=sharing [2] https://github.com/fog/fog [3] https://github.com/cloudfoundry/cf-release/blob/master/jobs/cloud_controller_ng/spec#L250-L251 Mit freundlichen Grüßen / Kind regards Simon Moser Senior Technical Staff Member / IBM Master Inventor Bluemix Application Platform Lead Architect Dept. C727, IBM Research & Development Boeblingen ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Schoenaicher Str. 220 71032 Boeblingen Phone: +49-7031-16-4304 Fax: +49-7031-16-4890 E-Mail: smoser(a)de.ibm.com ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 ** Great minds discuss ideas; average minds discuss events; small minds discuss people. Eleanor Roosevelt
|
|
|
|
Re: Issue with crashing Windows apps on Diego
Eric Malm <emalm@...>
Hi, Aaron and Matt,
toggle quoted messageShow quoted text
Thanks for the thoughtful discussion of the Windows health-check issue. I too think for consistency that if the CF end user has specified 'port' as the type of health-check on their app, then the platform should be checking only TCP connectivity to the app on that port, and not any layer-7 functionality beyond that. Some background on the HTTP vs TCP behavior in the health-check: originally, the health-check binary used for the buildpack and docker app lifecycles made only TCP connections to the requested port. When Lattice made it possible to submit DesiredLRPs directly to the Diego API, we got feedback from its users that they wanted an option to specify an HTTP-based health-check as well. Consequently, we extended that health-check binary to take an optional endpoint flag, and in its presence the binary would make a GET request to the specified endpoint and check for a response with a 200 OK status code within the specified timeout (default 1s). For buildpack and docker CF apps, though, none of that HTTP functionality has been exposed through CC, and only the basic TCP connectivity check is available. Matt, the native NetCheckAction from the Diego Dev Notes proposal you mention is effectively just encoding the current behavior of that TCP-or-HTTP health-check binary as an action that the rep could perform itself, rather that by invoking that binary in-container. The Diego team had conceived of it primarily as a performance optimization, particularly when starting a lot of instances on a cell simultaneously, but investigation revealed it to be of secondary benefit at best. The Diego team might implement it at some point, but for now we'd prefer not to expand the surface area of the Diego BBS API to include it. I've been meaning to update and close out that Dev Notes issue, and will do so shortly. In any case, the options on that proposed NetCheckAction are just the ones already available on the health-check binary, and, native action or not, additional work would still be required to expose them through CC to the CF end-user. Moreover, I don't think they're sufficient to address all the concerns that Aaron raises in his observations about the Windows app lifecycle's current HTTP-based check. Aaron, you mentioned timeout and expected status code as important parameters to specify on an HTTP health-check; are there others? I would think endpoint could be just as useful: perhaps your app has a /health or /ping endpoint specifically designed to return a fast response about the app itself, separate from backing services and/or authentication checks, or perhaps it simply doesn't handle requests to /. Thanks, Eric
On Tue, Feb 2, 2016 at 1:50 PM, aaron_huber <aaron.m.huber(a)intel.com> wrote:
My concern is that the HTTP check (mislabeled as "port") would still be the
|
|
|
|
Re: Wildcard routes, subdomains and failing smoke-test
Dieu Cao <dcao@...>
You might consider making a tiny custom 404 app and then map *.cf.bar.io
toggle quoted messageShow quoted text
and *.foo.bar.io and any other sub domains to it so that it doesn't fall through to your landing page app. Would that work for you? -Dieu CF CAPI PM
On Wed, Feb 3, 2016 at 12:46 AM, Engelke, Johannes <info(a)johannes-engelke.de
wrote: Hi,
|
|
|
|
Wildcard routes, subdomains and failing smoke-test
Engelke, Johannes <info@...>
Hi,
we got the following problem and I would like to know, if you have an idea how to solve it. We setup a view domains: - bar.io - foo.bar.io - cf.bar.io Bar.io is used for all the end user related things like the landing page, documentation, etc. foo.bar.io is used for internal service endpoints and cf.bar.io is used for all stuff related to CF (api, uaa, login…) and some shared things like monitoring UI etc. I created a route *.bar.io to move all typos etc. of our customer touch points to the central landing page. I was expecting <random>.cf.bar.io will be still return an 404 Route not found. Now smoketests (using cf.bar.io) are failing, because the wildcard domain is working recursive for all subdomains and is returning the content of *.bar app. (See: https://github.com/cloudfoundry/cf-smoke-tests/blob/master/smoke/runtime/runtime_test.go#L87-L93 <https://github.com/cloudfoundry/cf-smoke-tests/blob/master/smoke/runtime/runtime_test.go#L87-L93>) *.bar.io -> landing-page-app *.cf.bar.io -> landing-page-app (why?) *.foo.bar.io -> landing-page-app (why?) So my question, were should we fix it? Should the gorouter not be recursive over subdomains? Should we change the smoketest? Or am I on the wrong track and we should do something else? Cheers Johannes
|
|
|
|
Re: Support for HTTP/2
Carlo Alberto Ferraris
With this limitation in mind, an upstream component could still terminateJust as a small followup, consider that companies might have internal regulations mandating how and where SSL termination needs to happen (Rakuten is among them, for example...). As described in my previous mail, there are workarounds (e.g. using a separate TLS session between LB/RP and gorouter) but this may add further deployment complexity (and overhead).
|
|
|
|
Re: Support for HTTP/2
Carlo Alberto Ferraris
Shannon,
in our design we have a reverse proxy colocated with the gorouter. [1] While we can clearly reencrypt data going over loopback TCP (or Unix sockets :D) to the gorouter... it sounds a little bit overkill. [1] https://github.com/cloudfoundry/gorouter/issues/110#issuecomment-169204139
|
|
|
