[JBoss JIRA] (JBIDE-17615) When runtime download asks to reenter credentials, it will not accept them even if valid
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17615?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-17615.
---------------------------------
Resolution: Done
The re-prompt dialog was fixed https://issues.jboss.org/browse/JBIDE-21963
> When runtime download asks to reenter credentials, it will not accept them even if valid
> ----------------------------------------------------------------------------------------
>
> Key: JBIDE-17615
> URL: https://issues.jboss.org/browse/JBIDE-17615
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Beta2
> Environment: JBDS 8.0.0.Beta2c B130
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.1.AM2
>
>
> I was playing around JBIDE-17601 - that JIRA is about the bug that JBoss.org credentials were not validated when you went through new archetype from central -> Download & Install. So you could enter anything and it would let you carry on. But once the real download is about to start, you will get a popup to enter the credentials again (since the downloader needs the correct password). Even if you now enter the correct credentials, it will ask you 2 more times and then fail on Incorrect password.
> Yes, this will be less likely to happen once JBIDE-17601 is fixed. But I suppose that the popup is in place exactly for the situation when the password needs to be corrected, so it should work, right?
> There may still be a valid use case to hit this issue (although a very rare case):
> 1. User starts the runtime download dialog, enters correct credentials, moves to license
> 2. User changes his password on jboss.org
> 3. User carries on in the dialog to actually start the download - now he will probably be asked to correct his credentials
> So in my opinion, if we already have a mechanism to ask for credentials again, then it should work. If you say this is not needed, then why even allow the popup?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-17615) When runtime download asks to reenter credentials, it will not accept them even if valid
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17615?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-17615:
--------------------------------
Fix Version/s: 4.4.1.AM2
(was: 4.2.x)
> When runtime download asks to reenter credentials, it will not accept them even if valid
> ----------------------------------------------------------------------------------------
>
> Key: JBIDE-17615
> URL: https://issues.jboss.org/browse/JBIDE-17615
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.2.0.Beta2
> Environment: JBDS 8.0.0.Beta2c B130
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.1.AM2
>
>
> I was playing around JBIDE-17601 - that JIRA is about the bug that JBoss.org credentials were not validated when you went through new archetype from central -> Download & Install. So you could enter anything and it would let you carry on. But once the real download is about to start, you will get a popup to enter the credentials again (since the downloader needs the correct password). Even if you now enter the correct credentials, it will ask you 2 more times and then fail on Incorrect password.
> Yes, this will be less likely to happen once JBIDE-17601 is fixed. But I suppose that the popup is in place exactly for the situation when the password needs to be corrected, so it should work, right?
> There may still be a valid use case to hit this issue (although a very rare case):
> 1. User starts the runtime download dialog, enters correct credentials, moves to license
> 2. User changes his password on jboss.org
> 3. User carries on in the dialog to actually start the download - now he will probably be asked to correct his credentials
> So in my opinion, if we already have a mechanism to ask for credentials again, then it should work. If you say this is not needed, then why even allow the popup?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-21939) datatypes.dtd and properties.dtd not present in xml catalog
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21939?page=com.atlassian.jira.plugi... ]
Rob Stryker updated JBIDE-21939:
--------------------------------
Fix Version/s: 4.4.1.AM2
(was: 4.4.x)
> datatypes.dtd and properties.dtd not present in xml catalog
> -----------------------------------------------------------
>
> Key: JBIDE-21939
> URL: https://issues.jboss.org/browse/JBIDE-21939
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.3.1.CR1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.4.1.AM2
>
>
> Maybe this is not an issue at all but need to check.
> While verifying JBIDE-21690, I noticed that there are two dtd files that are not referenced in plugin.xml of org.jboss.tools.as.catalog_3.1.1.CR1-v20160316-0026-B106.jar .
> {code}
> $ for i in `find schema -name '*.dtd'`; do grep $i plugin.xml >/dev/null || echo $i not found; done
> schema/dtd/datatypes.dtd not found
> schema/dtd/properties.dtd not found
> {code}
> Is this ok or not?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-21801) Can't Download Runtimes for JBoss EAP and JBoss Fuse using git account signup
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21801?page=com.atlassian.jira.plugi... ]
Rob Stryker resolved JBIDE-21801.
---------------------------------
Fix Version/s: 4.4.1.AM2
(was: 4.4.x)
Resolution: Cannot Reproduce Bug
I cannot replicate this any longer. When using the github social account to sign up for red hat developer, it asks me to provide a password.
Then, so long as I use the redhat developer username (ie, olliebeef) and correct password, it works... OR, if I use the email address I provided when using github social to sign up, i can also download using username olliebeef(a)mail.com and rh-dev password.
So this seems to be working by all accounts as far as I can tell.
> Can't Download Runtimes for JBoss EAP and JBoss Fuse using git account signup
> -----------------------------------------------------------------------------
>
> Key: JBIDE-21801
> URL: https://issues.jboss.org/browse/JBIDE-21801
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server, upstream
> Affects Versions: 4.3.1.Beta2
> Reporter: Aurélien Pupier
> Assignee: Rob Stryker
> Fix For: 4.4.1.AM2
>
> Attachments: 1-preferencepage.png, 2-selectRuntime.png, 3-clickDownLoadAndInstall.png, 4-selectEactVersion.png, 5-fillCredentials.png, 6-PleaseuseFollowingLink.png, 7-allInformationprovided.png
>
>
> first technical investigation:
> - the url used to retrieve information on the Terms and conditions page is (I put a breakpoint on DownloadmanagertermsAndConditionsFragment.getTCResponseString): https://developers.redhat.com/download-manager/rest/tc?downloadURL=https%...
> and it returns:
> {noformat}
> <?xml version="1.0" encoding="UTF-8"?>
> <result>
> <htmlText><![CDATA[It is no longer possible to accept terms and conditions in the wizard. Please, use <a href="https://developers.redhat.com/download-manager/file/jboss-fuse-6.2.1.GA-f...">following link</a> instead!]]></htmlText>
> <plainText><![CDATA[It is no longer possible to accept terms and conditions in the wizard. Please, use https://developers.redhat.com/download-manager/file/jboss-fuse-6.2.1.GA-f... instead!]]></plainText>
> <customParams>
> <param name="company" label="Company" />
> <param name="country" label="Country" >
> <options multiple="false">
> </options>
> </param>
> <param name="downloadURL" label="Downloaded file" >
> <options multiple="false">
> <option key="https://www.jboss.org/download-manager/content/origin/files/sha256/e5/e5b..."/>
> </options>
> </param>
> </customParams>
> </result>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22609) Provided wrong credentials, CDK server adapter says "started" even though it is not.
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22609?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-22609:
-------------------------------------
Unfortunately, we have no real way to recognize that the credentials are wrong. Once the vagrant up process completes, we do a vagrant status. vagrant status tells us the VM is "running".
As far as I can tell, this is functioning as intended. It properly displays an error as expected, warns them that the openshift is unreachable, etc.
The only thing I could reasonably see here is to change the error message in the dialog?
> Provided wrong credentials, CDK server adapter says "started" even though it is not.
> ------------------------------------------------------------------------------------
>
> Key: JBIDE-22609
> URL: https://issues.jboss.org/browse/JBIDE-22609
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdk
> Affects Versions: 4.4.0.Final
> Environment: Devstudio 10.0.0.GA (B33), CDK 2.1.RC4, Windows 10
> Reporter: Radim Hopp
> Assignee: Rob Stryker
> Priority: Critical
> Fix For: 4.4.x
>
>
> When CDK startup fails when it is provided wrong credentials (it fails on vagrant-registration), CDK server adapter sets its state to "started" and OS3 connection is created (even though OS3 is not running in vagrant) with some weird IP (10.0.2.15). Also error pops up saying "The CDK VM is up and running, but OpenShift is unreachable at url https://10.0.2.15:8443/healthz/ready". I really don't know where this IP comes from. I was able to reproduce it on Fedora using libvirt box and the IP was something like (192.168.x.x)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months