[JBoss JIRA] (ISPN-7254) Administration console - accesing content without needed permissions should display error meesage
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7254?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-7254:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Administration console - accesing content without needed permissions should display error meesage
> -------------------------------------------------------------------------------------------------
>
> Key: ISPN-7254
> URL: https://issues.jboss.org/browse/ISPN-7254
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.Alpha4
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
> Fix For: 9.0.0.Beta1
>
> Attachments: standalone-auth.xml
>
>
> Create user with admin role, but without ___script_manager and ___schema_manager roles
> Start the server with security enabled.
> e.g. standalone with attached configuration (but the issue is present in domain mode as well)
> bin/standalone.sh -c standalone-auth.xml
> click on cache container -> configuration
> result: the console is stuck with loading icon (it's still responding)
> Server log show:
> ERROR [org.jboss.as.controller.management-operation] (External Management Request Threads -- 9) WFLYCTL0013: Operation ("get-proto-schema-names") failed - address: ([
> "subsystem",
> "datagrid-infinispan",
> "cache-container",
> "local"
> ]) - failure description: "DGISPN0118: Failed to invoke operation: ISPN000287: Unauthorized access: subject 'Subject with principal(s): [org.jboss.as.core.security.SimplePrincipal@36ebcb, user@ManagementRealm, admin@ManagementRealm, InetAddressPrincipal <127.0.0.1/127.0.0.1>]' lacks 'BULK_READ' permission"
> Expected result: there should be an error message in the console informing the user that he doesn't have required permissions.
> *Another issue*: User have admin role, so he should be able to access configuration page, he shouldn't be able to access scripts and schemes configuration because he lacks ,___script_manager and ___schema_manager
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (HRJS-27) Support recovering from complete cluster restarts
by Galder Zamarreño (JIRA)
Galder Zamarreño created HRJS-27:
------------------------------------
Summary: Support recovering from complete cluster restarts
Key: HRJS-27
URL: https://issues.jboss.org/browse/HRJS-27
Project: Infinispan Javascript client
Issue Type: Enhancement
Reporter: Galder Zamarreño
Hot Rod JS client might forgets initial addresses after a topology update, which means that if all the address in the topology are lost, there's no possibility to get back to the initial address.
In essence, JS client should have the equivalent of ISPN-5283 implemented so that it can handle complete restarts.
Here's the chat I had with Gustavo on IRC on this topic:
{code}
<gustavonalle> this reminds of an issue in the Node.js client
> oh right!
<gustavonalle> if I confiure it with address A, it connects to A and
get B,C,D as topology, it removes A from its pool
> which issue?
> ah yes!
> you mentioned it
<gustavonalle> A is the stable address to obtain initial topology
{code}
Once implemented, verify it works as expected by running the example in: https://github.com/gustavonalle/nodejs-infinispan
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ISPN-7313) AbstractFileLookup.lookupFileStrict broken on Windows
by Stefan Engel (JIRA)
[ https://issues.jboss.org/browse/ISPN-7313?page=com.atlassian.jira.plugin.... ]
Stefan Engel updated ISPN-7313:
-------------------------------
Description:
The fix in ISPN-5949 breaks Windows compatibility.
infinispan.xml is configured in application.properties
{noformat}
spring.cache.jcache.config=classpath:spring/infinispan.xml
{noformat}
When using Infinispan in a Spring Boot application (fat jar or Eclipse IDE) the following exception is thrown:
{noformat}
Caused by: org.infinispan.commons.CacheConfigurationException:
com.ctc.wstx.exc.WstxIOException: Stream closed
at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:119)
at org.infinispan.jcache.embedded.JCacheManager.getConfigurationBuilderHolder(JCacheManager.java:100)
at org.infinispan.jcache.embedded.JCacheManager.<init>(JCacheManager.java:56)
at org.infinispan.jcache.embedded.JCachingProvider.createCacheManager(JCachingProvider.java:46)
at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:67)
at org.springframework.boot.autoconfigure.cache.JCacheCacheConfiguration.createCacheManager(JCacheCacheConfiguration.java:101)
...
{noformat}
When {{AbstractFileLookup.lookupFileStrict()}} is called in {{JCacheManager.getConfigurationHolder()}} the URI used for infinispan.xml looks something like this:
* fat jar
{noformat}
jar:file:/C:/projects/myapp/myservice-0.0.1.jar!/spring/infinispan.xml
{noformat}
* running app from within IDE
{noformat}
file:/C:/projects/workspace/myservice/target/classes/spring/infinispan.xml
{noformat}
The problem ist now twofold:
# First this nasty 'C:' in the Windows path breaks the parsing code in {{AbstractFileLookup.lookupFileStrict()}}, as {{lastIndexOf(':')}} cuts the drive letter from the path and not just 'jar:file:' as intended. The resulting {{fileName}} cannot be resolved and {{cl.getResourceAsStream(fileName)}} returns {{null}}.
{code}
public InputStream lookupFileStrict(URI uri, ClassLoader cl) throws FileNotFoundException {
//in case we don't have only file schema, but {{jar:file}} schema too, we have to get rid of all schemas
int startIndex = uri.toString().lastIndexOf(':');
String fileName = uri.toString().substring(startIndex + 1);
return cl.getResourceAsStream(fileName);
}
{code}
# This method gets called too when running from within an IDE (at least Eclipse with Maven integration). But in this case Spring JCacheCacheConfiguration magic (createCachemanager() - configLocation.getURI()) resolves this path to a full path as seen above (not a classpath relative to {{/target/classes}}). As this path ist not on the classpath, {{cl.getResourceAsStream(fileName)}} returns {{null}}.
In both cases {{lookupFileStrict}} returns {{null}} as {{InputStream}} which in turn leads to the exception mentioned above.
The old code of {{lookupFileStrict()}}
{code}
return new FileInputStream(new File(uri));
{code}
works fine from within the IDE, but is broken for a fat jar (ISPN-5949).
I am currently trying to find a workaround for this. But as far as I can see, the current behaviour (fix or no fix) is going to a problem when developing/running Infinispan enabled applications on Windows.
was:
The fix in ISPN-5949 breaks Windows compatibility.
infinispan.xml ist configured in application.properties
{noformat}
spring.cache.jcache.config=classpath:spring/infinispan.xml
{noformat}
When using Infinispan in a Spring Boot application (fat jar or Eclipse IDE) the following exception is thrown:
{noformat}
Caused by: org.infinispan.commons.CacheConfigurationException:
com.ctc.wstx.exc.WstxIOException: Stream closed
at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:119)
at org.infinispan.jcache.embedded.JCacheManager.getConfigurationBuilderHolder(JCacheManager.java:100)
at org.infinispan.jcache.embedded.JCacheManager.<init>(JCacheManager.java:56)
at org.infinispan.jcache.embedded.JCachingProvider.createCacheManager(JCachingProvider.java:46)
at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:67)
at org.springframework.boot.autoconfigure.cache.JCacheCacheConfiguration.createCacheManager(JCacheCacheConfiguration.java:101)
...
{noformat}
When {{AbstractFileLookup.lookupFileStrict()}} is called in {{JCacheManager.getConfigurationHolder()}} the URI used for infinispan.xml looks something like this:
* fat jar
{noformat}
jar:file:/C:/projects/myapp/myservice-0.0.1.jar!/spring/infinispan.xml
{noformat}
* running app from within IDE
{noformat}
file:/C:/projects/workspace/myservice/target/classes/spring/infinispan.xml
{noformat}
The problem ist now twofold:
# First this nasty 'C:' in the Windows path breaks the parsing code in {{AbstractFileLookup.lookupFileStrict()}}, as {{lastIndexOf(':')}} cuts the drive letter from the path and not just 'jar:file:' as intended. The resulting {{fileName}} cannot be resolved and {{cl.getResourceAsStream(fileName)}} returns {{null}}.
{code}
public InputStream lookupFileStrict(URI uri, ClassLoader cl) throws FileNotFoundException {
//in case we don't have only file schema, but {{jar:file}} schema too, we have to get rid of all schemas
int startIndex = uri.toString().lastIndexOf(':');
String fileName = uri.toString().substring(startIndex + 1);
return cl.getResourceAsStream(fileName);
}
{code}
# This method gets called too when running from within an IDE (at least Eclipse with Maven integration). But in this case Spring JCacheCacheConfiguration magic (createCachemanager() - configLocation.getURI()) resolves this path to a full path as seen above (not a classpath relative to {{/target/classes}}). As this path ist not on the classpath, {{cl.getResourceAsStream(fileName)}} returns {{null}}.
In both cases {{lookupFileStrict}} returns {{null}} as {{InputStream}} which in turn leads to the exception mentioned above.
The old code of {{lookupFileStrict()}}
{code}
return new FileInputStream(new File(uri));
{code}
works fine from within the IDE, but is broken for a fat jar (ISPN-5949).
I am currently trying to find a workaround for this. But as far as I can see, the current behaviour (fix or no fix) is going to a problem when developing/running Infinispan enabled applications on Windows.
> AbstractFileLookup.lookupFileStrict broken on Windows
> -----------------------------------------------------
>
> Key: ISPN-7313
> URL: https://issues.jboss.org/browse/ISPN-7313
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha4, 9.0.0.Beta1
> Environment: Using Infinispan as JCache provider in Spring Boot (v1.3.5) application on Windows (either IDE (Eclipse) or fat jar).
> Reporter: Stefan Engel
>
> The fix in ISPN-5949 breaks Windows compatibility.
> infinispan.xml is configured in application.properties
> {noformat}
> spring.cache.jcache.config=classpath:spring/infinispan.xml
> {noformat}
> When using Infinispan in a Spring Boot application (fat jar or Eclipse IDE) the following exception is thrown:
> {noformat}
> Caused by: org.infinispan.commons.CacheConfigurationException:
> com.ctc.wstx.exc.WstxIOException: Stream closed
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:119)
> at org.infinispan.jcache.embedded.JCacheManager.getConfigurationBuilderHolder(JCacheManager.java:100)
> at org.infinispan.jcache.embedded.JCacheManager.<init>(JCacheManager.java:56)
> at org.infinispan.jcache.embedded.JCachingProvider.createCacheManager(JCachingProvider.java:46)
> at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:67)
> at org.springframework.boot.autoconfigure.cache.JCacheCacheConfiguration.createCacheManager(JCacheCacheConfiguration.java:101)
> ...
> {noformat}
> When {{AbstractFileLookup.lookupFileStrict()}} is called in {{JCacheManager.getConfigurationHolder()}} the URI used for infinispan.xml looks something like this:
> * fat jar
> {noformat}
> jar:file:/C:/projects/myapp/myservice-0.0.1.jar!/spring/infinispan.xml
> {noformat}
> * running app from within IDE
> {noformat}
> file:/C:/projects/workspace/myservice/target/classes/spring/infinispan.xml
> {noformat}
> The problem ist now twofold:
> # First this nasty 'C:' in the Windows path breaks the parsing code in {{AbstractFileLookup.lookupFileStrict()}}, as {{lastIndexOf(':')}} cuts the drive letter from the path and not just 'jar:file:' as intended. The resulting {{fileName}} cannot be resolved and {{cl.getResourceAsStream(fileName)}} returns {{null}}.
> {code}
> public InputStream lookupFileStrict(URI uri, ClassLoader cl) throws FileNotFoundException {
> //in case we don't have only file schema, but {{jar:file}} schema too, we have to get rid of all schemas
> int startIndex = uri.toString().lastIndexOf(':');
> String fileName = uri.toString().substring(startIndex + 1);
> return cl.getResourceAsStream(fileName);
> }
> {code}
> # This method gets called too when running from within an IDE (at least Eclipse with Maven integration). But in this case Spring JCacheCacheConfiguration magic (createCachemanager() - configLocation.getURI()) resolves this path to a full path as seen above (not a classpath relative to {{/target/classes}}). As this path ist not on the classpath, {{cl.getResourceAsStream(fileName)}} returns {{null}}.
> In both cases {{lookupFileStrict}} returns {{null}} as {{InputStream}} which in turn leads to the exception mentioned above.
> The old code of {{lookupFileStrict()}}
> {code}
> return new FileInputStream(new File(uri));
> {code}
> works fine from within the IDE, but is broken for a fat jar (ISPN-5949).
> I am currently trying to find a workaround for this. But as far as I can see, the current behaviour (fix or no fix) is going to a problem when developing/running Infinispan enabled applications on Windows.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ISPN-7313) AbstractFileLookup.lookupFileStrict broken on Windows
by Stefan Engel (JIRA)
Stefan Engel created ISPN-7313:
----------------------------------
Summary: AbstractFileLookup.lookupFileStrict broken on Windows
Key: ISPN-7313
URL: https://issues.jboss.org/browse/ISPN-7313
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.0.0.Beta1, 9.0.0.Alpha4
Environment: Using Infinispan as JCache provider in Spring Boot (v1.3.5) application on Windows (either IDE (Eclipse) or fat jar).
Reporter: Stefan Engel
The fix in ISPN-5949 breaks Windows compatibility.
infinispan.xml ist configured in application.properties
{noformat}
spring.cache.jcache.config=classpath:spring/infinispan.xml
{noformat}
When using Infinispan in a Spring Boot application (fat jar or Eclipse IDE) the following exception is thrown:
{noformat}
Caused by: org.infinispan.commons.CacheConfigurationException:
com.ctc.wstx.exc.WstxIOException: Stream closed
at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:119)
at org.infinispan.jcache.embedded.JCacheManager.getConfigurationBuilderHolder(JCacheManager.java:100)
at org.infinispan.jcache.embedded.JCacheManager.<init>(JCacheManager.java:56)
at org.infinispan.jcache.embedded.JCachingProvider.createCacheManager(JCachingProvider.java:46)
at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:67)
at org.springframework.boot.autoconfigure.cache.JCacheCacheConfiguration.createCacheManager(JCacheCacheConfiguration.java:101)
...
{noformat}
When {{AbstractFileLookup.lookupFileStrict()}} is called in {{JCacheManager.getConfigurationHolder()}} the URI used for infinispan.xml looks something like this:
* fat jar
{noformat}
jar:file:/C:/projects/myapp/myservice-0.0.1.jar!/spring/infinispan.xml
{noformat}
* running app from within IDE
{noformat}
file:/C:/projects/workspace/myservice/target/classes/spring/infinispan.xml
{noformat}
The problem ist now twofold:
# First this nasty 'C:' in the Windows path breaks the parsing code in {{AbstractFileLookup.lookupFileStrict()}}, as {{lastIndexOf(':')}} cuts the drive letter from the path and not just 'jar:file:' as intended. The resulting {{fileName}} cannot be resolved and {{cl.getResourceAsStream(fileName)}} returns {{null}}.
{code}
public InputStream lookupFileStrict(URI uri, ClassLoader cl) throws FileNotFoundException {
//in case we don't have only file schema, but {{jar:file}} schema too, we have to get rid of all schemas
int startIndex = uri.toString().lastIndexOf(':');
String fileName = uri.toString().substring(startIndex + 1);
return cl.getResourceAsStream(fileName);
}
{code}
# This method gets called too when running from within an IDE (at least Eclipse with Maven integration). But in this case Spring JCacheCacheConfiguration magic (createCachemanager() - configLocation.getURI()) resolves this path to a full path as seen above (not a classpath relative to {{/target/classes}}). As this path ist not on the classpath, {{cl.getResourceAsStream(fileName)}} returns {{null}}.
In both cases {{lookupFileStrict}} returns {{null}} as {{InputStream}} which in turn leads to the exception mentioned above.
The old code of {{lookupFileStrict()}}
{code}
return new FileInputStream(new File(uri));
{code}
works fine from within the IDE, but is broken for a fat jar (ISPN-5949).
I am currently trying to find a workaround for this. But as far as I can see, the current behaviour (fix or no fix) is going to a problem when developing/running Infinispan enabled applications on Windows.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ISPN-7209) Collation not set properly when data stored via Hot Rod when JdbcStringBasedStore is used with MariaDB
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7209?page=com.atlassian.jira.plugin.... ]
Ryan Emerson resolved ISPN-7209.
--------------------------------
Resolution: Won't Fix
Resolving as won't fix as there are multiple workarounds.
> Collation not set properly when data stored via Hot Rod when JdbcStringBasedStore is used with MariaDB
> ------------------------------------------------------------------------------------------------------
>
> Key: ISPN-7209
> URL: https://issues.jboss.org/browse/ISPN-7209
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha4
> Reporter: Jiří Holuša
> Assignee: Ryan Emerson
>
> Given following scenario:
> 1) store entry to ISPN server via Hot Rod (e.g. with RemoteCache)
> 2) have the server configured to use JdbcStringBasedStore
> 3) used database is MariaDB 10
> Following exception is thrown:
> {code}
> ERROR [org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore] (HotRodServerHandler-3-2) ISPN008024: Error while storing string key to database; key: '9A09AJAAAAAAAAA==': java.sql.BatchUpdateException: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='
> {code}
> Note that his doesn't happen when stored via, for example, Memcached client. Also this issue doesn't appear in library mode, doesn't appear in any with any other database (including MySQL, which is very similar to MariaDB).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months