Cloud Foundry Eclipse plugin 1.6 with Cloud Foundry 163 - cannot authenticate

307 views
Skip to first unread message

Nicolas Regez

unread,
Apr 7, 2014, 10:17:50 AM4/7/14
to vcap...@cloudfoundry.org
Hi Nieraj

I've observed that the Cloud Foundry Eclipse plugin in not able to connect to our Cloud Foundry install running version 163.
Connecting to an install running 153, it works perfectly.

The problem araises during the setup of the connection in the "new server" wizard, at the moment I test the connection by pushing the button "Validate Account", it tells me "Wrong email or password". I thought this might be related to changes in uaa API?

Do you know about this problem already? Can you help me resolving it? Is there anything else I can contribute to the resolution of this issue?

Best regards,
Nic

James Bayer

unread,
Apr 9, 2014, 11:07:23 AM4/9/14
to vcap...@cloudfoundry.org
nic,

i've been using the new plugin version [1] against api.run.pivotal.io and not had any issues other than some installation snags that were resolved where the plugins where being hosted from. run.pivotal.io is now on cf-release v166 i believe. i think you may be able to see some troubleshooting detail using the Window -> Show View -> General -> Error Log

let us know if you still have problems.

[1] 1.6.0.201402241821-RELEASE


To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.



--
Thank you,

James Bayer

wxl...@gmail.com

unread,
Apr 10, 2014, 7:21:21 PM4/10/14
to vcap...@cloudfoundry.org
Can I just confirm that I'm having the same problem but the difference is that it works when I deploy to run.pivotal.io but fails when deploying to our private lab PaaS.  I'm not sure what's different between the two environments:

James Bayer

unread,
Apr 11, 2014, 2:04:03 AM4/11/14
to vcap...@cloudfoundry.org
it's likely that you're using a self-signed certificate in the lab that is not from a CA whereas run.pivotal.io is using a trusted CA. the new eclipse plugin should let you opt-in to self-signed certsi think, i can't remember where that option is off-hand. when ryan morgan comes back from break he should be able to indicate that.


To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

Scott Frederick

unread,
Apr 11, 2014, 10:54:04 AM4/11/14
to vcap...@cloudfoundry.org
If the CF Eclipse plugin gets an SSL certificate error on the first connection attempt, it will re-try with self-signed cert support enabled. I don't believe there is an explicit option to enable this. 

The rules for accepting a self-signed cert are pretty strict. The cert chain must have a depth of exactly 1 (i.e. the self-signed cert must be at the root of the chain) and the hostname of the CF API endpoint must match the CN domain of the cert (with wildcards allowed)[1]. 

I don't know if this has anything to do with the auth problems you are having.

Scott

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+unsubscribe@cloudfoundry.org.

N Singh

unread,
Apr 11, 2014, 1:20:13 PM4/11/14
to vcap...@cloudfoundry.org
Just to confirm what Scott mentioned, as of CF 1.6.0, CF Eclipse will only detect and prompt the user to continue with private clouds using self-signed certificates when the private URL is initially added to CF Eclipse via "Manage Cloud" in the new server wizard and an initial credentials validation is performed.

Once the user makes a decision, CF Eclipse will remember it for subsequent server creations or server cloning to that URL. To "clear" this decision, the URL can be removed from "Manage Cloud" and added again after launching the New Server wizard again. We hope to improve how server URLs are managed in future releases through a separate preferences page.

-Nieraj

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

Nicolas Regez

unread,
Apr 14, 2014, 9:53:10 AM4/14/14
to vcap...@cloudfoundry.org
Hello Nieraj

Thanks all for your answers and statements. First, we do not use a self-signed certificate here. We use an officially signed wildcard certificate with a pattern that perfectly matches the certificate on api.run.pivotal.io, namely the DN = "*.appcloud-beta.swisscom.com"

Second, we have CF instances running version 153 where the Eclipse Plugin works, while the two installations running 163 (one with certificate mentioned above, annother with a self-signed certificate) both do not work. So my wild guess is the issue I am facing is not related to certificates.

- James, unfortunately, there are no entries in Eclipse Error-Log view.
- The plugin version perfectly matches: 1.6.0.201402241821-RELEASE
- By-the-way, as we do not have a self-signed certificate, I do not get prompted whether to allow self-signed certificates of not during the "manage-cloud" step of the wizard.

Any other hint for me?
Nic

N Singh

unread,
Apr 15, 2014, 1:02:33 PM4/15/14
to vcap...@cloudfoundry.org

Hi,

I verified to see what errors will generate "Wrong email or password" in the tooling, just in case it gets generated by some other error not related to authentication, and I see this message is displayed only when the CF Eclipse plug-in receives HTTP 401 or 403 errors. Have you tried using the command line tool 'cf', and does it generate the same Unauthorised/Forbidden errors?

Thanks.

-Nieraj

N Singh

unread,
Apr 16, 2014, 2:07:47 PM4/16/14
to vcap...@cloudfoundry.org
As a follow-up, we have just released CF Eclipse 1.6.1. It is available from the general CF Eclipse update site:

http://dist.springsource.com/release/TOOLS/cloudfoundry

If you have a chance to update to 1.6.1 and verify if the problem still persists that would be great. Thank you.

-Nieraj

Guillaume Berche

unread,
Apr 23, 2014, 12:03:55 PM4/23/14
to vcap...@cloudfoundry.org
We observe the same issue with Cf eclipse 1.6.1 running against our private CF v161 accessed using http: the "validate" button errors with "invalid email or password". The same process works on run.pivotal.io

The "Window -> Show View -> General -> Error Log" or "console output" do not show errors.

Is there a way to enable verbose traces (ideally the wire traces that gcf outputs when CF_TRACE=true is specified) ?

Thanks in advance,

Guillaume.

N Singh

unread,
Apr 28, 2014, 6:29:29 PM4/28/14
to vcap...@cloudfoundry.org
Hi,

We're currently adding verbose tracing to CF Eclipse. We hope to have it available in the CF nightly update site, hopefully by the end of this week. There will be an Eclipse preference page setting where you can enable verbose tracing, and we hope this can help in trying to debug issues with validating credentials with private clouds.

I'll post a separate message when we have a nightly build available with verbose tracing.

Thanks.

-Nieraj

Nicolas Regez

unread,
May 5, 2014, 10:47:38 AM5/5/14
to vcap...@cloudfoundry.org
Hi Nieraj

Thank you for your helping us with this issue. Please let us know when the new version with the tracing becomes available so I can use it to analyze further.

Best regards
Nic

N Singh

unread,
May 7, 2014, 2:01:14 PM5/7/14
to vcap...@cloudfoundry.org
Hi,

We have added basic verbose HTTP tracing in CF Eclipse. It is available from the latest nightly build, if you want to update your current CF Eclipse installation, please use this URL:

http://dist.springsource.com/snapshot/TOOLS/cloudfoundry/nightly

In Help -> Install New Software menu, and in the URL text widget, paste the URL above and hit enter.

Once updated, and STS/Eclipse restarts, to enable verbose HTTP tracing, please do the following:

1. Go to STS/Eclipse menu -> Preferences -> Cloud Foundry -> HTTP Tracing, and check on the box and click Apply or OK
2. This will open a Cloud Foundry Console in the Eclipse Console view.
3. Perform any CF operation (e.g. start an application or open New Server wizard, enter credentials, and click "Validate"), and you should see HTTP verbose output in the trace console.
4. To disable tracing, repeat Step 1 and uncheck the box.

A few things to note:

- This is a nightly build, and is updated frequently. Although we do our best to keep it stable, it may on occasion be unstable, so if you notice instabilities please wait a few days to update to a newer version. A final stable HTTP tracing feature will be available in the upcoming CF Eclipse 1.6.2 release later this month.

- HTTP tracing is meant as a secondary way to debug primarily back-end (server) issues, usually meant to generate data for technical support, so we only intend to enable/disable via the preference page.

- At the moment, there is only one trace console, and it will display HTTP trace output for ALL connected Cloud Foundry server instances. If there is a need to restrict it to a particular server instance, please let us know.

- It is not currently showing HTTP headers. If you require this as part of the verbose tracing, please let us know.

- The CF Trace console can only be created and shown via the preference page. Once it is created, it will remain in the Consoles view. You have the option of manually pinning it via the Consoles view if you don't want it to be sent to the background, in case some other console is made visible by another Eclipse component. There is a drop-down menu in the Console view that shows all "hidden" consoles. If you notice that the CF Trace console is no longer visible, please check this dropdown menu.

- Not all CF client requests are currently logged. If you perform an operation and do not see any verbose tracing in the console, please let us know.

If possible, we'd like to request that any issues or feedback regarding the trace feature in CF Eclipse , or any other CF Eclipse issue, be directed to:

https://groups.google.com/a/cloudfoundry.org/forum/#!forum/cf-eclipse

or issues raised here:

https://github.com/cloudfoundry/eclipse-integration-cloudfoundry

Thanks.

-Nieraj

Nicolas Regez

unread,
May 16, 2014, 11:36:19 AM5/16/14
to vcap...@cloudfoundry.org
Hi Nieraj

Thanks for your detailed reply and for adding the feature to trace HTTP traffic.
I installed Version: 1.6.1.201405060141-CI-B791 following your instructions above.
I checked "HTTP Tracing" in the preferences.
Then, I started the wizard, entered my credentials and on "Validate Account" got again the message "Wrong email or password - 403 (Forbidden)".
Intrestingly, it took 20 seconds to produce the error message, so I guess there is some timeout as well in the processing chain, right?

Unfortunately, there is no output in the "Cloud Foundry Trace" console.

Best regards
Nic

N Singh

unread,
May 23, 2014, 7:27:17 PM5/23/14
to vcap...@cloudfoundry.org
Hi,

Thanks for the additional information. I was wondering if you can try it out in the command line with 'cf', and see if you experience the same delays. Unfortunately, it seems credential authorisation request in the Java client may not be logging the trace. We hope to have that fixed in the upcoming client release as well as CF Eclipse 1.6.2., which should be released within 2 weeks.

 Sorry that there doesn't seem to be much else that can be done from the Eclipse side to investigate the matter further, although if you can try the command line tool to see if you encounter the same issues it will help to determine if it is a Eclipse or Java client issue or backend problem.

Thank you.

-Nieraj

Guillaume Berche

unread,
Jun 11, 2014, 1:25:53 PM6/11/14
to vcap...@cloudfoundry.org

I was reproducing the same issue trying to connect through http (I haven't yet installed an SSL termination such as https://github.com/cloudfoundry-community/sslproxy-boshrelease ).

In my case, this seems to be due to an invalid bosh CF manifest that was specifiying https urls instead of http urls for the following properties: uaa.no_ssl: false, uaa.url, ccng.srv_api_uri, cc.srv_api_uri, uaa.clients.login.redirect-uri:

you can easily verify that with on the info endpoint:

$ cf curl info
{"name":"vcap","build":"2222","support":"http://support.cloudfoundry.com","version":2,"description":"Cloud Foundry sponsored by Pivotal","authorization_endpoint":"http://login.my.org","token_endpoint":"http://uaa.my.org","allow_debug":true}


See related issue cloudfoundry/cf-release#419 on how I fixed the cf bosh manifest. This solved the authentication issue in both maven and eclipse.

Seems the go cli has a different behavior and works around the invalid info returned by the /info endpoint

Hope this helps others,

Guillaume.
Reply all
Reply to author
Forward
0 new messages