[JBoss JIRA] (ISPN-12320) Disabling authentication per endpoint is not possible
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-12320?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-12320:
--------------------------------
Summary: Disabling authentication per endpoint is not possible (was: Enabling authentication per endpoint is not possible)
> Disabling authentication per endpoint is not possible
> -----------------------------------------------------
>
> Key: ISPN-12320
> URL: https://issues.redhat.com/browse/ISPN-12320
> Project: Infinispan
> Issue Type: Bug
> Components: Hot Rod, REST, Security
> Affects Versions: 12.0.0.Dev03
> Reporter: Ryan Emerson
> Assignee: Tristan Tarrant
> Priority: Major
>
> Currently it's not possible to configure the server so that authentication is only enabled on either the REST or HotRod endpoint. When utilising authentication elements on either endpoint it's mandatory for the `<endpoints ...` `security-realm` attribute to be set, otherwise the following exception is thrown:
> {code:java}
> 11:04:12,367 FATAL (main) [org.infinispan.SERVER] ISPN080028: Infinispan Server failed to start org.infinispan.commons.CacheConfigurationException: ISPN080021: Authentication cannot be configured without a security realm
> at org.infinispan.server.configuration.hotrod.HotRodServerConfigurationParser.parseAuthentication(HotRodServerConfigurationParser.java:204)
> at org.infinispan.server.configuration.hotrod.HotRodServerConfigurationParser.parseHotRodConnector(HotRodServerConfigurationParser.java:111)
> at org.infinispan.server.configuration.hotrod.HotRodServerConfigurationParser.readElement(HotRodServerConfigurationParser.java:56)
> at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:224)
> at org.infinispan.configuration.parsing.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:60)
> at org.infinispan.server.configuration.ServerConfigurationParser.parseEndpoints(ServerConfigurationParser.java:1126)
> at org.infinispan.server.configuration.ServerConfigurationParser.parseServerElements(ServerConfigurationParser.java:121)
> at org.infinispan.server.configuration.ServerConfigurationParser.readElement(ServerConfigurationParser.java:92)
> at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:224)
> at org.infinispan.configuration.parsing.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:60)
> at org.infinispan.configuration.parsing.Parser.readElement(Parser.java:127)
> at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:224)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:194)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:180)
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:169)
> at org.infinispan.server.Server.parseConfiguration(Server.java:270)
> at org.infinispan.server.Server.<init>(Server.java:198)
> at org.infinispan.server.Bootstrap.runInternal(Bootstrap.java:138)
> at org.infinispan.server.tool.Main.run(Main.java:98)
> at org.infinispan.server.Bootstrap.main(Bootstrap.java:40)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.infinispan.server.loader.Loader.run(Loader.java:76)
> at org.infinispan.server.loader.Loader.main(Loader.java:39)
> {code}
> However, setting the security-realm attribute means that authentication is automatically configured for endpoints that do no have a {{<authentication>}} element set. So the following xml always results in REST authentication being enabled.
> {code:xml}
> <endpoints socket-binding="default" security-realm="default">
> <hotrod-connector name="hotrod">
> <authentication>
> <sasl mechanisms="SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256 SCRAM-SHA-1 DIGEST-SHA-512 DIGEST-SHA-384 DIGEST-SHA-256 DIGEST-SHA DIGEST-MD5 PLAIN" />
> </authentication>
> </hotrod-connector>
> <rest-connector name="rest"/>
> </endpoints>
> {code}
> It should be possible for REST auth to be disabled and HotRod auth enabled and vice-versa.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (ISPN-12320) Enabling authentication per endpoint is not possible
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-12320:
-----------------------------------
Summary: Enabling authentication per endpoint is not possible
Key: ISPN-12320
URL: https://issues.redhat.com/browse/ISPN-12320
Project: Infinispan
Issue Type: Bug
Components: Hot Rod, REST, Security
Affects Versions: 12.0.0.Dev03
Reporter: Ryan Emerson
Assignee: Tristan Tarrant
Currently it's not possible to configure the server so that authentication is only enabled on either the REST or HotRod endpoint. When utilising authentication elements on either endpoint it's mandatory for the `<endpoints ...` `security-realm` attribute to be set, otherwise the following exception is thrown:
{code:java}
11:04:12,367 FATAL (main) [org.infinispan.SERVER] ISPN080028: Infinispan Server failed to start org.infinispan.commons.CacheConfigurationException: ISPN080021: Authentication cannot be configured without a security realm
at org.infinispan.server.configuration.hotrod.HotRodServerConfigurationParser.parseAuthentication(HotRodServerConfigurationParser.java:204)
at org.infinispan.server.configuration.hotrod.HotRodServerConfigurationParser.parseHotRodConnector(HotRodServerConfigurationParser.java:111)
at org.infinispan.server.configuration.hotrod.HotRodServerConfigurationParser.readElement(HotRodServerConfigurationParser.java:56)
at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:224)
at org.infinispan.configuration.parsing.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:60)
at org.infinispan.server.configuration.ServerConfigurationParser.parseEndpoints(ServerConfigurationParser.java:1126)
at org.infinispan.server.configuration.ServerConfigurationParser.parseServerElements(ServerConfigurationParser.java:121)
at org.infinispan.server.configuration.ServerConfigurationParser.readElement(ServerConfigurationParser.java:92)
at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:224)
at org.infinispan.configuration.parsing.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:60)
at org.infinispan.configuration.parsing.Parser.readElement(Parser.java:127)
at org.infinispan.configuration.parsing.ParserRegistry.parseElement(ParserRegistry.java:224)
at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:194)
at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:180)
at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:169)
at org.infinispan.server.Server.parseConfiguration(Server.java:270)
at org.infinispan.server.Server.<init>(Server.java:198)
at org.infinispan.server.Bootstrap.runInternal(Bootstrap.java:138)
at org.infinispan.server.tool.Main.run(Main.java:98)
at org.infinispan.server.Bootstrap.main(Bootstrap.java:40)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.infinispan.server.loader.Loader.run(Loader.java:76)
at org.infinispan.server.loader.Loader.main(Loader.java:39)
{code}
However, setting the security-realm attribute means that authentication is automatically configured for endpoints that do no have a {{<authentication>}} element set. So the following xml always results in REST authentication being enabled.
{code:xml}
<endpoints socket-binding="default" security-realm="default">
<hotrod-connector name="hotrod">
<authentication>
<sasl mechanisms="SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256 SCRAM-SHA-1 DIGEST-SHA-512 DIGEST-SHA-384 DIGEST-SHA-256 DIGEST-SHA DIGEST-MD5 PLAIN" />
</authentication>
</hotrod-connector>
<rest-connector name="rest"/>
</endpoints>
{code}
It should be possible for REST auth to be disabled and HotRod auth enabled and vice-versa.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (ISPN-12310) Describe the protobuf error message
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-12310?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-12310:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 11.0.4.Final
12.0.0.Dev04
Resolution: Done
> Describe the protobuf error message
> -----------------------------------
>
> Key: ISPN-12310
> URL: https://issues.redhat.com/browse/ISPN-12310
> Project: Infinispan
> Issue Type: Feature Request
> Components: Console
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Priority: Major
> Fix For: 11.0.4.Final, 12.0.0.Dev04
>
>
> Create a protobuf with
>
> {code:java}
> package book_sample;
> message Book {
> optional string title = 1;
> optional string description = 2;
> optional int publicationYear = 3;
> }{code}
> It will show: *Schema book.proto has errors*
>
> If you inspect the response you will see: *cause: "Failed to resolve type of field "book_sample.Book.publicationYear". Type not found : int"*
>
> It is better to show what is the error
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (ISPN-12318) Query.maxResult() ignored during entity loading
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12318?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12318:
-------------------------------------
Description:
When a query has a maxResult it should not try to load/collect/read/hidrate all hits but rather restrict it to the requested page size. This causes unnecessary allocations of Strings and byte[]. In particular, the {{KeyTransformationHandler#stringToKey}} method produces a large amount of garbage.
Other issue is the default maxResult is not defined consistently: it is 10 for queries over REST and undefined for embedded and queries over Hot Rod.
was:
When a query has a maxResult it should not try to load/collect/read/hidrate all results but rather restrict it to the requested page size. This causes unnecessary allocations of Strings and byte[]. In particular, the {{KeyTransformationHandler#stringToKey}} method produces a large amount of garbage.
Other issue is the default maxResult is not defined consistently: it is 10 for queries over REST and undefined for embedded and queries over Hot Rod.
> Query.maxResult() ignored during entity loading
> -----------------------------------------------
>
> Key: ISPN-12318
> URL: https://issues.redhat.com/browse/ISPN-12318
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 12.0.0.Dev03
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Critical
>
> When a query has a maxResult it should not try to load/collect/read/hidrate all hits but rather restrict it to the requested page size. This causes unnecessary allocations of Strings and byte[]. In particular, the {{KeyTransformationHandler#stringToKey}} method produces a large amount of garbage.
> Other issue is the default maxResult is not defined consistently: it is 10 for queries over REST and undefined for embedded and queries over Hot Rod.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (ISPN-12318) Query.maxResult() ignored during entity loading
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12318?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12318:
-------------------------------------
Description:
When a query has a maxResult it should not try to load collect all results but rather restrict it to the requested page size. This causes unnecessary allocations of Strings and byte[]. In particular, the {{KeyTransformationHandler#stringToKey}} method produces a large amount of garbage.
Other issue is the default maxResult is not defined consistently: it is 10 for queries over REST and undefined for embedded and queries over Hot Rod.
was:
When a query has a maxResult it should not try to load all results from the cache but rather restrict it to the requested page size. This causes unnecessary allocations of Strings and byte[]. In particular, the {{KeyTransformationHandler#stringToKey}} method produces a large amount of garbage.
Other issue is the default maxResult is not defined consistently: it is 10 for queries over REST and undefined for embedded and queries over Hot Rod.
> Query.maxResult() ignored during entity loading
> -----------------------------------------------
>
> Key: ISPN-12318
> URL: https://issues.redhat.com/browse/ISPN-12318
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 12.0.0.Dev03
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Critical
>
> When a query has a maxResult it should not try to load collect all results but rather restrict it to the requested page size. This causes unnecessary allocations of Strings and byte[]. In particular, the {{KeyTransformationHandler#stringToKey}} method produces a large amount of garbage.
> Other issue is the default maxResult is not defined consistently: it is 10 for queries over REST and undefined for embedded and queries over Hot Rod.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (ISPN-12318) Query.maxResult() ignored during entity loading
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12318?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12318:
-------------------------------------
Description:
When a query has a maxResult it should not try to load/collect/read/hidrate all results but rather restrict it to the requested page size. This causes unnecessary allocations of Strings and byte[]. In particular, the {{KeyTransformationHandler#stringToKey}} method produces a large amount of garbage.
Other issue is the default maxResult is not defined consistently: it is 10 for queries over REST and undefined for embedded and queries over Hot Rod.
was:
When a query has a maxResult it should not try to load collect all results but rather restrict it to the requested page size. This causes unnecessary allocations of Strings and byte[]. In particular, the {{KeyTransformationHandler#stringToKey}} method produces a large amount of garbage.
Other issue is the default maxResult is not defined consistently: it is 10 for queries over REST and undefined for embedded and queries over Hot Rod.
> Query.maxResult() ignored during entity loading
> -----------------------------------------------
>
> Key: ISPN-12318
> URL: https://issues.redhat.com/browse/ISPN-12318
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 12.0.0.Dev03
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Critical
>
> When a query has a maxResult it should not try to load/collect/read/hidrate all results but rather restrict it to the requested page size. This causes unnecessary allocations of Strings and byte[]. In particular, the {{KeyTransformationHandler#stringToKey}} method produces a large amount of garbage.
> Other issue is the default maxResult is not defined consistently: it is 10 for queries over REST and undefined for embedded and queries over Hot Rod.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (ISPN-12316) Convert expiration to no longer use transactions
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-12316?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-12316:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 12.0.0.Dev04
(was: 12.0.0.Final)
Resolution: Done
> Convert expiration to no longer use transactions
> ------------------------------------------------
>
> Key: ISPN-12316
> URL: https://issues.redhat.com/browse/ISPN-12316
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 12.0.0.Dev04
>
>
> Currently when an entry is expired we remove it via the transactional mode of the cache, ie. if transaction we start a new transaction. We should instead always remove these elements in a non transactional way similar to putForExternalRead. This will make transaction processing much simpler as there is only one mode instead of 3+.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (ISPN-12317) WildFly modules integration tests do not start after surefire 3.0.0-M5 upgrade
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-12317?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-12317:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> WildFly modules integration tests do not start after surefire 3.0.0-M5 upgrade
> ------------------------------------------------------------------------------
>
> Key: ISPN-12317
> URL: https://issues.redhat.com/browse/ISPN-12317
> Project: Infinispan
> Issue Type: Bug
> Components: Build, Test Suite
> Affects Versions: 12.0.0.Dev03
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 12.0.0.Dev04
>
>
> The {{integrationtests/server-integration/wildfly-modules}} tests do not start because of a {{NoClassDefFoundError}}:
> {noformat}
> ./integrationtests/server-integration/wildfly-modules/target/failsafe-reports/2020-09-07T07-11-49_195-jvmRun1.dump
> # Created at 2020-09-07T07:24:46.704
> java.lang.NoClassDefFoundError: org/infinispan/test/integration/as/client/AbstractHotRodClientIT
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1096)
> at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:206)
> at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:759)
> at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:680)
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:605)
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> at org.apache.maven.surefire.api.util.DefaultScanResult.loadClass(DefaultScanResult.java:136)
> at org.apache.maven.surefire.api.util.DefaultScanResult.applyFilter(DefaultScanResult.java:100)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.scanClassPath(JUnitCoreProvider.java:292)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.setTestsToRun(JUnitCoreProvider.java:198)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:132)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> Caused by: java.lang.ClassNotFoundException: org.infinispan.test.integration.as.client.AbstractHotRodClientIT
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> ... 19 more
> {noformat}
> Further investigation shows that {{AbstractHotRodClientIT}} does exist on the classpath, but the classloader is trying to load it from the wrong jar: {{infinispan-wildfly-module-integrationtests-12.0.0-SNAPSHOT.jar}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years