July 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-22756) Connection: varioius weirdness in token/password

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22756?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22756: ------------------------------------- Fix Version/s: 4.4.1.AM2 > Connection: varioius weirdness in token/password > ------------------------------------------------- > > Key: JBIDE-22756 > URL: https://issues.jboss.org/browse/JBIDE-22756 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: openshift > Affects Versions: 4.4.1.AM2 > Reporter: Andre Dietisheim > Labels: connection > Fix For: 4.4.1.AM2 > > > The lifecycle of the token is rather weird and needs a consistent logic: > When connecting via wizard the token is set in the connection wizard: > {code:title=ConnectionWizardPageModel#connect} > ... > try { > IConnection connection = createConnection(connectionFactory, connectionAuthenticationProvider); > ... > {code} > {code:title=ConnectionWizardPageModel#createConnection} > ... > if (authProvider != null) { > authProvider.update(connection); // sets the token > } > ... > {code} > {code:title=BearTokenAuthenticationProvider#update} > ... > connection.setAuthScheme(IAuthorizationContext.AUTHSCHEME_OAUTH); > connection.setToken(tokenObservable.getValue()); > connection.setRememberToken(rememberTokenObservable.getValue()); > ... > {code} > {code:title=Connection#connect} > if(authorize()) { > ... > {code} > {code:title=Connection#authorized} > ... > if (context.isAuthorized()) { > String username = context.getUser().getName(); > String token = context.getToken(); > updateAuthorized(username, token); > } else { > ... > {code} > The token is then fetched from client and set to the connection > {code:title=Connection#updateAuthorized} > setToken(token); > ... > {code} > and the password is cleared > {code:Connectoin#savePasswordOrToken} > } else if (IAuthorizationContext.AUTHSCHEME_OAUTH.equals(getAuthScheme())){ > boolean success = saveOrClear(SECURE_STORAGE_TOKEN_KEY, this.token, isRememberToken()); > if(success) { > //Avoid second secure storage prompt. > //Token is stored, password should be cleared. > clearPassword(); > {code} > I suspect the aim here is to clear existing password in secure storage if the user is switching password->token based auth (and vice versa) > The opposite is then not fully congruent. The token is only cleared in secure storage, not in Connection instance var > {code:title=Connection#savePasswordOrToken} > if (IAuthorizationContext.AUTHSCHEME_BASIC.equals(getAuthScheme())) { > boolean success = saveOrClear(SECURE_STORAGE_PASSWORD_KEY, this.password, isRememberPassword()); > if (success) { > //Avoid second secure storage prompt. > // Password is stored, token should be cleared. > clearToken(); > } > {code:Connection#clearToken} > // dont clear the token instance var: JBIDE-22594 > setRememberToken(false); > saveOrClear(SECURE_STORAGE_TOKEN_KEY, null, false); > {code} > I suspect that we should only clear in secure storage, not in the Connection instance as we see in JBIDE-22594 (for the opposite case where we dont clear the token in the Connection instance). But then one has to keep in mind that all auth is token based. Even if you auth via password initially, the auth is then switched to token based once the authorization succeeded and we got a token: > {code:title=Connection#updateAuthorized} > setToken(token); > if (IAuthorizationContext.AUTHSCHEME_OAUTH.equalsIgnoreCase(getAuthScheme())) { > setUsername(username); > } > // force auth strategy to token if authorized > TokenAuthorizationStrategy tokenStrategy = new TokenAuthorizationStrategy(token, username); > client.setAuthorizationStrategy(tokenStrategy); > {code} > Another issue is that the connection and the auth schemeare both stored in different classes. The connection is stored via > {code:title=ConnectionPersistency#persist} > preferences.saveConnections(connections.keySet().toArray(new String[] {})); > ... > {code} > while the auth scheme is stored in Connection#saveAuthSchemePreference: > {code:title=Connection#connect} > saveAuthSchemePreference(); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22756) Connection: varioius weirdness in token/password

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22756?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-22756: ------------------------------------- Labels: connection (was: ) > Connection: varioius weirdness in token/password > ------------------------------------------------- > > Key: JBIDE-22756 > URL: https://issues.jboss.org/browse/JBIDE-22756 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: openshift > Affects Versions: 4.4.1.AM2 > Reporter: Andre Dietisheim > Labels: connection > Fix For: 4.4.1.AM2 > > > The lifecycle of the token is rather weird and needs a consistent logic: > When connecting via wizard the token is set in the connection wizard: > {code:title=ConnectionWizardPageModel#connect} > ... > try { > IConnection connection = createConnection(connectionFactory, connectionAuthenticationProvider); > ... > {code} > {code:title=ConnectionWizardPageModel#createConnection} > ... > if (authProvider != null) { > authProvider.update(connection); // sets the token > } > ... > {code} > {code:title=BearTokenAuthenticationProvider#update} > ... > connection.setAuthScheme(IAuthorizationContext.AUTHSCHEME_OAUTH); > connection.setToken(tokenObservable.getValue()); > connection.setRememberToken(rememberTokenObservable.getValue()); > ... > {code} > {code:title=Connection#connect} > if(authorize()) { > ... > {code} > {code:title=Connection#authorized} > ... > if (context.isAuthorized()) { > String username = context.getUser().getName(); > String token = context.getToken(); > updateAuthorized(username, token); > } else { > ... > {code} > The token is then fetched from client and set to the connection > {code:title=Connection#updateAuthorized} > setToken(token); > ... > {code} > and the password is cleared > {code:Connectoin#savePasswordOrToken} > } else if (IAuthorizationContext.AUTHSCHEME_OAUTH.equals(getAuthScheme())){ > boolean success = saveOrClear(SECURE_STORAGE_TOKEN_KEY, this.token, isRememberToken()); > if(success) { > //Avoid second secure storage prompt. > //Token is stored, password should be cleared. > clearPassword(); > {code} > I suspect the aim here is to clear existing password in secure storage if the user is switching password->token based auth (and vice versa) > The opposite is then not fully congruent. The token is only cleared in secure storage, not in Connection instance var > {code:title=Connection#savePasswordOrToken} > if (IAuthorizationContext.AUTHSCHEME_BASIC.equals(getAuthScheme())) { > boolean success = saveOrClear(SECURE_STORAGE_PASSWORD_KEY, this.password, isRememberPassword()); > if (success) { > //Avoid second secure storage prompt. > // Password is stored, token should be cleared. > clearToken(); > } > {code:Connection#clearToken} > // dont clear the token instance var: JBIDE-22594 > setRememberToken(false); > saveOrClear(SECURE_STORAGE_TOKEN_KEY, null, false); > {code} > I suspect that we should only clear in secure storage, not in the Connection instance as we see in JBIDE-22594 (for the opposite case where we dont clear the token in the Connection instance). But then one has to keep in mind that all auth is token based. Even if you auth via password initially, the auth is then switched to token based once the authorization succeeded and we got a token: > {code:title=Connection#updateAuthorized} > setToken(token); > if (IAuthorizationContext.AUTHSCHEME_OAUTH.equalsIgnoreCase(getAuthScheme())) { > setUsername(username); > } > // force auth strategy to token if authorized > TokenAuthorizationStrategy tokenStrategy = new TokenAuthorizationStrategy(token, username); > client.setAuthorizationStrategy(tokenStrategy); > {code} > Another issue is that the connection and the auth schemeare both stored in different classes. The connection is stored via > {code:title=ConnectionPersistency#persist} > preferences.saveConnections(connections.keySet().toArray(new String[] {})); > ... > {code} > while the auth scheme is stored in Connection#saveAuthSchemePreference: > {code:title=Connection#connect} > saveAuthSchemePreference(); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22757) jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22757?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22757: ------------------------------------ This affects parent pom and jbosstools-cleanup.sh too: {code} <deployTargetFolder>${jbosstools-build-type}/${JOB_NAME}/${BUILD_ID}-B${BUILD_NUMBER}/all/repo/</deployTargetFolder> {code} https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.3.x/u... So... yeah. This is big. > jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug) > ----------------------------------------------------------------- > > Key: JBIDE-22757 > URL: https://issues.jboss.org/browse/JBIDE-22757 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.AM2 > > Attachments: buildID-broken.png > > > Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. > [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 > [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 > So instead of timestamped build folders, we're seeing things like this: > !buildID-broken.png|thumbnail! > Workaround until fixed in Jenkins: > {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} > Or, try using BUILD_TIMESTAMP instead? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22757) jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22757?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22757: ------------------------------- Priority: Blocker (was: Major) > jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug) > ----------------------------------------------------------------- > > Key: JBIDE-22757 > URL: https://issues.jboss.org/browse/JBIDE-22757 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Blocker > Fix For: 4.4.1.AM2 > > Attachments: buildID-broken.png > > > Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. > [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 > [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 > So instead of timestamped build folders, we're seeing things like this: > !buildID-broken.png|thumbnail! > Workaround until fixed in Jenkins: > {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} > Or, try using BUILD_TIMESTAMP instead? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22757) jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22757?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22757: ------------------------------- Description: Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 So instead of timestamped build folders, we're seeing things like this: !buildID-broken.png|thumbnail! Workaround until fixed in Jenkins: {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} Or, try using BUILD_TIMESTAMP instead? was: Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 So instead of timestamped build folders, we're seeing things like this: !buildID-broken.png! Workaround until fixed in Jenkins: {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} Or, try using BUILD_TIMESTAMP instead? > jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug) > ----------------------------------------------------------------- > > Key: JBIDE-22757 > URL: https://issues.jboss.org/browse/JBIDE-22757 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.AM2 > > Attachments: buildID-broken.png > > > Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. > [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 > [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 > So instead of timestamped build folders, we're seeing things like this: > !buildID-broken.png|thumbnail! > Workaround until fixed in Jenkins: > {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} > Or, try using BUILD_TIMESTAMP instead? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22757) jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22757?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22757: ------------------------------- Description: Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 So instead of timestamped build folders, we're seeing things like this: Workaround until fixed in Jenkins: {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} Or, try using BUILD_TIMESTAMP instead? was: Due to an upstream bug in Jenkins [1], BUILD_ID now = BUILD_NUMBER. [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 So instead of timestamped build folders, we're seeing things like this: Workaround until fixed in Jenkins: {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} Or, try using BUILD_TIMESTAMP instead? > jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug) > ----------------------------------------------------------------- > > Key: JBIDE-22757 > URL: https://issues.jboss.org/browse/JBIDE-22757 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.AM2 > > Attachments: buildID-broken.png > > > Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. > [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 > [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 > So instead of timestamped build folders, we're seeing things like this: > Workaround until fixed in Jenkins: > {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} > Or, try using BUILD_TIMESTAMP instead? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22757) jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22757?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22757: ------------------------------- Description: Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 So instead of timestamped build folders, we're seeing things like this: !buildID-broken.png! Workaround until fixed in Jenkins: {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} Or, try using BUILD_TIMESTAMP instead? was: Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 So instead of timestamped build folders, we're seeing things like this: Workaround until fixed in Jenkins: {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} Or, try using BUILD_TIMESTAMP instead? > jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug) > ----------------------------------------------------------------- > > Key: JBIDE-22757 > URL: https://issues.jboss.org/browse/JBIDE-22757 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.AM2 > > Attachments: buildID-broken.png > > > Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. > [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 > [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 > So instead of timestamped build folders, we're seeing things like this: > !buildID-broken.png! > Workaround until fixed in Jenkins: > {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} > Or, try using BUILD_TIMESTAMP instead? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22757) jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22757?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22757: ------------------------------- Attachment: buildID-broken.png > jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug) > ----------------------------------------------------------------- > > Key: JBIDE-22757 > URL: https://issues.jboss.org/browse/JBIDE-22757 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.AM2 > > Attachments: buildID-broken.png > > > Due to an upstream bug in Jenkins [1], [2], BUILD_ID now = BUILD_NUMBER. > [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 > [2] https://issues.jenkins-ci.org/browse/JENKINS-26626 > So instead of timestamped build folders, we're seeing things like this: > Workaround until fixed in Jenkins: > {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} > Or, try using BUILD_TIMESTAMP instead? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22757) jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug)

by Nick Boldt (JIRA)

Nick Boldt created JBIDE-22757: ---------------------------------- Summary: jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug) Key: JBIDE-22757 URL: https://issues.jboss.org/browse/JBIDE-22757 Project: Tools (JBoss Tools) Issue Type: Bug Components: build Affects Versions: 4.4.1.AM2 Reporter: Nick Boldt Due to an upstream bug in Jenkins [1], BUILD_ID now = BUILD_NUMBER. [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 So instead of timestamped build folders, we're seeing things like this: Workaround until fixed in Jenkins: {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} Or, try using BUILD_TIMESTAMP instead? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22757) jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22757?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-22757: ---------------------------------- Assignee: Nick Boldt > jenkins jobs no longer using BUILD_ID = a timestamp (Jenkins bug) > ----------------------------------------------------------------- > > Key: JBIDE-22757 > URL: https://issues.jboss.org/browse/JBIDE-22757 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.AM2 > > > Due to an upstream bug in Jenkins [1], BUILD_ID now = BUILD_NUMBER. > [1] https://issues.jenkins-ci.org/browse/JENKINS-26520 > So instead of timestamped build folders, we're seeing things like this: > Workaround until fixed in Jenkins: > {code}BUILD_ID=`date -u +%Y-%m-%d_%H-%M-%S`{code} > Or, try using BUILD_TIMESTAMP instead? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues July 2016