March 2014 - gatein-issues - Jboss List Archives

[JBoss JIRA] (GTNPORTAL-3418) Improve Redirect Admin UI to be W3C compliant

by Lucas Ponce (JIRA)

Lucas Ponce created GTNPORTAL-3418: -------------------------------------- Summary: Improve Redirect Admin UI to be W3C compliant Key: GTNPORTAL-3418 URL: https://issues.jboss.org/browse/GTNPORTAL-3418 Project: GateIn Portal Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Lucas Ponce Assignee: Lucas Ponce -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3415) URL query parameters are lost in the authentication process with LegacyRequestHandler

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3415?page=com.atlassian.jira.pl... ] Trong Tran updated GTNPORTAL-3415: ---------------------------------- Original Estimate: 3 hours (was: 0 minutes) Remaining Estimate: 3 hours (was: 0 minutes) > URL query parameters are lost in the authentication process with LegacyRequestHandler > ------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3415 > URL: https://issues.jboss.org/browse/GTNPORTAL-3415 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.5.8.Final > Reporter: Martin Weiler > Fix For: 3.8.0.Final > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > Steps to reproduce > - Goto url http://localhost:8080/portal/private/classic/home/restricted?myparameter=... > --> it redirect to login page, login as root --> Query parameters are lost. > Note: Without the LegacyRequestHandler - http://localhost:8080/portal/classic/home/restricted?myparameter=TEST - the parameters are preserved with the fix for GTNPORTAL-3389 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3414) Oauth improvement: enable developer change the way to generate gatein user for each oauth provider via extension

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3414?page=com.atlassian.jira.pl... ] Trong Tran updated GTNPORTAL-3414: ---------------------------------- Original Estimate: 4 hours Remaining Estimate: 4 hours > Oauth improvement: enable developer change the way to generate gatein user for each oauth provider via extension > ---------------------------------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3414 > URL: https://issues.jboss.org/browse/GTNPORTAL-3414 > Project: GateIn Portal > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Tuyen Nguyen The > Assignee: Tuyen Nguyen The > Attachments: linkedin-registration.png > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When i register new account with LinkedIn, i see a registration form with random-string username prefilled (see attachment) > It's because LinkedIn does not provide username as unique attribute for each user, so we have to get userid instead of username, and this is a random-string by LinkedIn > Now, We can improvement method OAuthUtils#convertOAuthPrincipalToGateInUser() and customize the way to convert oauth-principal to gatein user for linkedIn. > But when someone provide other oauth integration via extension, he can not customize OAuthUtils#convertOAuthPrincipalToGateInUser() method to generate gatein user by the way that oauth should do. > So we should enable developer change the way to generate gatein user for each oauth provider via extension. > To enable developer change the way to generate gatein user via extension, we will: > - Introduce OAuthUserGenerator service and it can add OAuthUserGeneratorPlugin by extension. This service will response to generate gatein user from oauth-principal > - Method OAuthUserGenerator#generateGateInUser(OAuthPrincipal principal) will do: > + Find OAuthUserGeneratorPlugin by oauthProviderType, > + If found plugin for this oauth provider it will delegate method OAuthUserGeneratorPlugin#generateGateInUser() > + If not found, it will delegate to OAuthUtils#convertOAuthPrincipalToGateInUser() as default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3415) URL query parameters are lost in the authentication process with LegacyRequestHandler

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3415?page=com.atlassian.jira.pl... ] Trong Tran updated GTNPORTAL-3415: ---------------------------------- Sprint: Sprint 94, Sprint 96 (was: Sprint 94) > URL query parameters are lost in the authentication process with LegacyRequestHandler > ------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3415 > URL: https://issues.jboss.org/browse/GTNPORTAL-3415 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.5.8.Final > Reporter: Martin Weiler > Fix For: 3.8.0.Final > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Steps to reproduce > - Goto url http://localhost:8080/portal/private/classic/home/restricted?myparameter=... > --> it redirect to login page, login as root --> Query parameters are lost. > Note: Without the LegacyRequestHandler - http://localhost:8080/portal/classic/home/restricted?myparameter=TEST - the parameters are preserved with the fix for GTNPORTAL-3389 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3414) Oauth improvement: enable developer change the way to generate gatein user for each oauth provider via extension

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3414?page=com.atlassian.jira.pl... ] Trong Tran updated GTNPORTAL-3414: ---------------------------------- Sprint: Sprint 96 > Oauth improvement: enable developer change the way to generate gatein user for each oauth provider via extension > ---------------------------------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3414 > URL: https://issues.jboss.org/browse/GTNPORTAL-3414 > Project: GateIn Portal > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Tuyen Nguyen The > Assignee: Tuyen Nguyen The > Attachments: linkedin-registration.png > > > When i register new account with LinkedIn, i see a registration form with random-string username prefilled (see attachment) > It's because LinkedIn does not provide username as unique attribute for each user, so we have to get userid instead of username, and this is a random-string by LinkedIn > Now, We can improvement method OAuthUtils#convertOAuthPrincipalToGateInUser() and customize the way to convert oauth-principal to gatein user for linkedIn. > But when someone provide other oauth integration via extension, he can not customize OAuthUtils#convertOAuthPrincipalToGateInUser() method to generate gatein user by the way that oauth should do. > So we should enable developer change the way to generate gatein user for each oauth provider via extension. > To enable developer change the way to generate gatein user via extension, we will: > - Introduce OAuthUserGenerator service and it can add OAuthUserGeneratorPlugin by extension. This service will response to generate gatein user from oauth-principal > - Method OAuthUserGenerator#generateGateInUser(OAuthPrincipal principal) will do: > + Find OAuthUserGeneratorPlugin by oauthProviderType, > + If found plugin for this oauth provider it will delegate method OAuthUserGeneratorPlugin#generateGateInUser() > + If not found, it will delegate to OAuthUtils#convertOAuthPrincipalToGateInUser() as default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3415) URL query parameters are lost in the authentication process with LegacyRequestHandler

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3415?page=com.atlassian.jira.pl... ] Trong Tran updated GTNPORTAL-3415: ---------------------------------- Fix Version/s: 3.8.0.Final > URL query parameters are lost in the authentication process with LegacyRequestHandler > ------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3415 > URL: https://issues.jboss.org/browse/GTNPORTAL-3415 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.5.8.Final > Reporter: Martin Weiler > Fix For: 3.8.0.Final > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Steps to reproduce > - Goto url http://localhost:8080/portal/private/classic/home/restricted?myparameter=... > --> it redirect to login page, login as root --> Query parameters are lost. > Note: Without the LegacyRequestHandler - http://localhost:8080/portal/classic/home/restricted?myparameter=TEST - the parameters are preserved with the fix for GTNPORTAL-3389 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3404) The path of JCr index cache is hard coded in configuration.properties

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3404?page=com.atlassian.jira.pl... ] Trong Tran updated GTNPORTAL-3404: ---------------------------------- Original Estimate: 4 hours (was: 30 minutes) Remaining Estimate: 4 hours (was: 30 minutes) > The path of JCr index cache is hard coded in configuration.properties > --------------------------------------------------------------------- > > Key: GTNPORTAL-3404 > URL: https://issues.jboss.org/browse/GTNPORTAL-3404 > Project: GateIn Portal > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 3.7.0.Final > Reporter: Racha Touzi > Assignee: Tuyen Nguyen The > Priority: Minor > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The path 's configuration of the JCR index cache is always configured in cluster mode "/conf/jcr/infinispan/cluster/indexer-config.xml" whatever the profil mode ( local or cluster) . > But in local mode we don't really need the transport configuration and the clustering configuration > {code} > <infinispan > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="urn:infinispan:config:5.2 http://www.infinispan.org/schemas/infinispan-config-5.2.xsd" > xmlns="urn:infinispan:config:5.2"> > <global> > <evictionScheduledExecutor factory="org.infinispan.executors.DefaultScheduledExecutorFactory"> > <properties> > <property name="threadNamePrefix" value="EvictionThread"/> > </properties> > </evictionScheduledExecutor> > <globalJmxStatistics jmxDomain="platform.insp.cache.indexer" enabled="true" allowDuplicateDomains="true"/> > <transport transportClass="org.infinispan.remoting.transport.jgroups.JGroupsTransport" clusterName="${infinispan-cluster-name}" distributedSyncTimeout="20000"> > <properties> > <property name="configurationFile" value="${gatein.jcr.jgroups.config}"/> > </properties> > </transport> > </global> > <default> > <clustering mode="replication"> > <stateTransfer timeout="20000" fetchInMemoryState="false" /> > <sync replTimeout="20000"/> > </clustering> > <locking isolationLevel="READ_COMMITTED" lockAcquisitionTimeout="20000" writeSkewCheck="false" concurrencyLevel="500" useLockStriping="false"/> > <transaction transactionManagerLookupClass="org.exoplatform.services.transaction.infinispan.JBossStandaloneJTAManagerLookup" syncRollbackPhase="true" syncCommitPhase="true" transactionMode="TRANSACTIONAL"/> > <jmxStatistics enabled="true"/> > <eviction strategy="NONE"/> > <loaders passivation="false" shared="false" preload="false"> > <loader class="${infinispan-cachestore-classname}" fetchPersistentState="false" ignoreModifications="false" purgeOnStartup="false"> > <async enabled="false"/> > </loader> > </loaders> > </default> > </infinispan> > {code} > So , The configuration of JCR Index cache must be one for local mode and one for Cluster mode , > the path must be > {code} > gatein.jcr.index.cache.config=war:/conf/jcr/infinispan/${gatein.jcr.config.type}/indexer-config.xml > {code} > instead of > {code} > gatein.jcr.index.cache.config=war:/conf/jcr/infinispan/cluster/indexer-config.xml > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3404) The path of JCr index cache is hard coded in configuration.properties

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3404?page=com.atlassian.jira.pl... ] Trong Tran updated GTNPORTAL-3404: ---------------------------------- Sprint: Sprint 95, Sprint 96 (was: Sprint 95) > The path of JCr index cache is hard coded in configuration.properties > --------------------------------------------------------------------- > > Key: GTNPORTAL-3404 > URL: https://issues.jboss.org/browse/GTNPORTAL-3404 > Project: GateIn Portal > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 3.7.0.Final > Reporter: Racha Touzi > Assignee: Tuyen Nguyen The > Priority: Minor > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > The path 's configuration of the JCR index cache is always configured in cluster mode "/conf/jcr/infinispan/cluster/indexer-config.xml" whatever the profil mode ( local or cluster) . > But in local mode we don't really need the transport configuration and the clustering configuration > {code} > <infinispan > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="urn:infinispan:config:5.2 http://www.infinispan.org/schemas/infinispan-config-5.2.xsd" > xmlns="urn:infinispan:config:5.2"> > <global> > <evictionScheduledExecutor factory="org.infinispan.executors.DefaultScheduledExecutorFactory"> > <properties> > <property name="threadNamePrefix" value="EvictionThread"/> > </properties> > </evictionScheduledExecutor> > <globalJmxStatistics jmxDomain="platform.insp.cache.indexer" enabled="true" allowDuplicateDomains="true"/> > <transport transportClass="org.infinispan.remoting.transport.jgroups.JGroupsTransport" clusterName="${infinispan-cluster-name}" distributedSyncTimeout="20000"> > <properties> > <property name="configurationFile" value="${gatein.jcr.jgroups.config}"/> > </properties> > </transport> > </global> > <default> > <clustering mode="replication"> > <stateTransfer timeout="20000" fetchInMemoryState="false" /> > <sync replTimeout="20000"/> > </clustering> > <locking isolationLevel="READ_COMMITTED" lockAcquisitionTimeout="20000" writeSkewCheck="false" concurrencyLevel="500" useLockStriping="false"/> > <transaction transactionManagerLookupClass="org.exoplatform.services.transaction.infinispan.JBossStandaloneJTAManagerLookup" syncRollbackPhase="true" syncCommitPhase="true" transactionMode="TRANSACTIONAL"/> > <jmxStatistics enabled="true"/> > <eviction strategy="NONE"/> > <loaders passivation="false" shared="false" preload="false"> > <loader class="${infinispan-cachestore-classname}" fetchPersistentState="false" ignoreModifications="false" purgeOnStartup="false"> > <async enabled="false"/> > </loader> > </loaders> > </default> > </infinispan> > {code} > So , The configuration of JCR Index cache must be one for local mode and one for Cluster mode , > the path must be > {code} > gatein.jcr.index.cache.config=war:/conf/jcr/infinispan/${gatein.jcr.config.type}/indexer-config.xml > {code} > instead of > {code} > gatein.jcr.index.cache.config=war:/conf/jcr/infinispan/cluster/indexer-config.xml > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (GTNWSRP-372) Exception appears in log while using WSRP portlets with PortletBridge

by Vlastislav Ramik (JIRA)

[ https://issues.jboss.org/browse/GTNWSRP-372?page=com.atlassian.jira.plugi... ] Vlastislav Ramik commented on GTNWSRP-372: ------------------------------------------ There are links to passed tests: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EPP/view/EPP/view/6... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EPP/view/EPP/view/6... > Exception appears in log while using WSRP portlets with PortletBridge > ---------------------------------------------------------------------- > > Key: GTNWSRP-372 > URL: https://issues.jboss.org/browse/GTNWSRP-372 > Project: GateIn WSRP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.2.11.Final > Reporter: Juraci Paixão Kröhling > Assignee: Juraci Paixão Kröhling > Fix For: 2.2.12.Final > > > From Bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1063918 : > The following exception will appear in server log after portlet initialization on the page. It has no affect on functionality, everything is working just fine and this exception is thrown only once. > How to reproduce > 1. Enable WSRP > 2. Deploy RichFaces Showcase portlet > 3. Add it to page as remote portlet > 4. See the exception at first access to Showcase > I enclose the Showcase portlet and .txt with exception log. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3417) Disable users icons look like inverse

by Vlastislav Ramik (JIRA)

Vlastislav Ramik created GTNPORTAL-3417: ------------------------------------------- Summary: Disable users icons look like inverse Key: GTNPORTAL-3417 URL: https://issues.jboss.org/browse/GTNPORTAL-3417 Project: GateIn Portal Issue Type: Bug Security Level: Public (Everyone can see) Environment: 3.8.0.Beta01-SNAPSHOT Reporter: Vlastislav Ramik Fix For: 3.8.0.Final Icons in users and group managements looks that all users are disabled while they are enabled. The icon is grey and the tag is: <img title="Disabled User" alt="Disabled User" ... /> While disabled user icons is green and the tag is: <img title="Enabled User" alt="Enabled User" ... /> All functionality works as expected but both the icon and the title is very confusing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-issues March 2014