[JBoss JIRA] (WFLY-8870) AuthenticationTestCase fails with security manager
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-8870?page=com.atlassian.jira.plugin.... ]
Yeray Borges reassigned WFLY-8870:
----------------------------------
Assignee: Yeray Borges
> AuthenticationTestCase fails with security manager
> --------------------------------------------------
>
> Key: WFLY-8870
> URL: https://issues.jboss.org/browse/WFLY-8870
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager, Test Suite
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Kotek
> Assignee: Yeray Borges
>
> *org.wildfly.test.integration.elytron.ejb.AuthenticationTestCase*
> There are missing permissions:
> * {{new PropertyPermission("jboss.bind.address", "read")}} required by {{TestSuiteEnvironment}} class,
> * {{new ElytronPermission("getSecurityDomain")}},
> * {{new ElytronPermission("authenticate")}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-801) ModifiableSecurityRealm#getRealmIdentityIterator() is a bit wrong
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-801?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse resolved ELY-801.
----------------------------------
Fix Version/s: 1.1.0.Beta53
Resolution: Done
> ModifiableSecurityRealm#getRealmIdentityIterator() is a bit wrong
> -----------------------------------------------------------------
>
> Key: ELY-801
> URL: https://issues.jboss.org/browse/ELY-801
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: David Lloyd
> Assignee: David Lloyd
> Priority: Minor
> Fix For: 1.1.0.Beta53
>
>
> After the fixes for iterator closing which pertain mainly to the file system realm, we have a new interface CloseableIterator which adds a close() method which throws IOException. However this doesn't fit the general mold for identity handling, and only the FS realm would ever throw IOException (others would throw SQLException or NamingException for example).
> Fix this in a couple ways:
> # Drop CloseableIterator and replace it with a ModifiableRealmIdentityIterator which extends {{Iterator<ModifiableRealmIdentity>}} and {{AutoCloseable}}
> # Override {{close()}} to throw {{RealmUnavailableException}}
> Then make the associated changes to the realm(s).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-801) ModifiableSecurityRealm#getRealmIdentityIterator() is a bit wrong
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-801?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-801:
------------------------------------
Assignee: David Lloyd
> ModifiableSecurityRealm#getRealmIdentityIterator() is a bit wrong
> -----------------------------------------------------------------
>
> Key: ELY-801
> URL: https://issues.jboss.org/browse/ELY-801
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: David Lloyd
> Assignee: David Lloyd
> Priority: Minor
>
> After the fixes for iterator closing which pertain mainly to the file system realm, we have a new interface CloseableIterator which adds a close() method which throws IOException. However this doesn't fit the general mold for identity handling, and only the FS realm would ever throw IOException (others would throw SQLException or NamingException for example).
> Fix this in a couple ways:
> # Drop CloseableIterator and replace it with a ModifiableRealmIdentityIterator which extends {{Iterator<ModifiableRealmIdentity>}} and {{AutoCloseable}}
> # Override {{close()}} to throw {{RealmUnavailableException}}
> Then make the associated changes to the realm(s).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-874) Make ServerAuthenticationContext implement AutoCloseable (with no exceptions)
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-874?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-874:
------------------------------------
Assignee: Farah Juma
> Make ServerAuthenticationContext implement AutoCloseable (with no exceptions)
> -----------------------------------------------------------------------------
>
> Key: ELY-874
> URL: https://issues.jboss.org/browse/ELY-874
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI
> Reporter: David Lloyd
> Assignee: Farah Juma
> Priority: Minor
> Fix For: 1.1.0.Beta53
>
>
> It's pretty easy to forget to clean up a ServerAuthenticationContext when using it directly for simple authentication. We can make this easier by making it implement AutoCloseable with a close() method that fails the authentication if it is still open.
> The logic would basically be similar to {{if (! isDone()) fail();}} but with the difference that it should be atomic, and it should not be declared to throw any exceptions because none are possible in this scenario.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JGRP-1440) JDBC_PING java.sql.SQLException: ORA-00001: unique constraint violated
by Matthew Buckett (JIRA)
[ https://issues.jboss.org/browse/JGRP-1440?page=com.atlassian.jira.plugin.... ]
Matthew Buckett commented on JGRP-1440:
---------------------------------------
Ah no {{writeToFile()}} is called both when fetching the cluster members ({{fetchClusterMembers()}}) and when updating it's entry ({{WriterTask.run()}}) so the synchronizing is still needed.
> JDBC_PING java.sql.SQLException: ORA-00001: unique constraint violated
> ----------------------------------------------------------------------
>
> Key: JGRP-1440
> URL: https://issues.jboss.org/browse/JGRP-1440
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.12.1
> Environment: windows xp, oracle 11G
> Reporter: freeliuade freeliuade
> Assignee: Sanne Grinovero
> Labels: JDBC_PING,
> Fix For: 3.1
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> using JDBC_PING, create a very simple JChannel, unique constraint violated exception will throw sometimes.
> it's a occationally issue. to easy reproduce it, using debug to let threads hold on JDBC_PING.writeToFile(...). line insert(...) (JDBC_PING line 246 in JGroups2.12.1.Final) you can find three threads will be hold on here. then using debug to step over this line, the unique constraint violated exception will throw.
> I uploaded a debug diagram in here http://ww2.sinaimg.cn/mw600/649a9869jw1dr8m399uqdj.jpg
> following is the exception stack:
> SEVERE: Error updating JDBC_PING table
> java.sql.SQLException: ORA-00001: unique constraint (HLIUCLUSTER.SYS_C0038277) violated
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
> at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
> at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:219)
> at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:970)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1190)
> at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3370)
> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3454)
> at org.jgroups.protocols.JDBC_PING.insert(JDBC_PING.java:265)
> at org.jgroups.protocols.JDBC_PING.writeToFile(JDBC_PING.java:246)
> at org.jgroups.protocols.FILE_PING.sendGetMembersRequest(FILE_PING.java:115)
> at org.jgroups.protocols.Discovery$PingSenderTask$1.run(Discovery.java:527)
> at org.jgroups.util.TimeScheduler2$RecurringTask.run(TimeScheduler2.java:592)
> at org.jgroups.util.TimeScheduler2$MyTask.run(TimeScheduler2.java:524)
> at org.jgroups.util.TimeScheduler2$Entry.execute(TimeScheduler2.java:429)
> at org.jgroups.util.TimeScheduler2$1.run(TimeScheduler2.java:295)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1255) Elytron client configuration file throws ConfigXMLParseException when credential certificate is used
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1255?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reassigned ELY-1255:
-------------------------------
Assignee: Jan Kalina (was: Pedro Igor)
> Elytron client configuration file throws ConfigXMLParseException when credential certificate is used
> ----------------------------------------------------------------------------------------------------
>
> Key: ELY-1255
> URL: https://issues.jboss.org/browse/ELY-1255
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta52
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> When Elytron client configuration file includes configuration.authentication-client.authentication-configurations.configuration.credentials.certificate element then ConfigXMLParseException is thrown during parsing of configuration file.
> For following configuration file:
> {code}
> <configuration>
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-rules>
> <rule use-configuration="default"/>
> </authentication-rules>
> <authentication-configurations>
> <configuration name="default">
> <sasl-mechanism-selector selector="PLAIN"/>
> <credentials>
> <certificate>
> <private-key-pem>
> -----BEGIN ENCRYPTED PRIVATE KEY-----
> MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQI/UbK4uSM+lICAggA
> MBQGCCqGSIb3DQMHBAjqSiGAFsiVUwSCBMg1UIOetO6ZNmBehx3pzNVqefIYE6wc
> 5roz1Yz0ZLroq9zFn8kGGe65XlZRD8jO7+pYgglHwII0s05P2YPRx8boHgNvf/de
> cYmPXOuT2W7obUQTRlM0TzJpjP+74cwmxeM0L/mvhRlQKgkHyFzIj3f0lJxlrCS5
> FiN8xM7YuDZ+nZwSil6pF+bCO/V/TAEsuR15eG2UHZuMeFgL9xez7ZPJPKDyeXIo
> deMz2sv63keJ6nIEAxq46+m53HKFcOs3kCCa/M2LQg0uxxA3YyjLiVu8U0k/ox7L
> rQ3XVBA11oBSUM9+vFl9CMW/7do/5niL3JNrz+e1FpG6ViG2MT+3+na7YfN+7ffp
> FUSblMFR9Px00uBfqVHufCzKotNX0VqbEGGCE40i1Tpq5ZWCob4R6/42zW+BctJO
> ZxUeiJJaXAoccvJiZRraicte6OpDMWZXPIKMR+FIc1YXuWYv3BHHhfZKhLm8tuxb
> eSNE8vRR/exfV1z+YoZ0nvwOhpBOK7yQl9iqOy+eQ7e7h85yv15XFX2cOjPgY4bO
> M3wN6H41K5eUock6UYaKLY2qzVlyI0rwV1aYnnrGeA5gHkfAFdPNpxm7+ejUAi2z
> am117gT3NXKCLq0SsV55wjonAcN9ghN8X46tWZIO0chlNpVOHZSUz/NtavOrmZwZ
> UcFajPKvoT3V7t8hGD1Tg1AdChahlIjT5dzDQBaHtJLbz7qPljHuAvvZR/bapTdW
> 97zMxp3zRQbyHqPmu6BFUASgXHnKLY6Cu1a0w+AhVaemWLLVeHMweWlLsLAHxSo4
> qkqIkn8rMr9V92/nVaE6fEnmplnWTI3VY3t0vzI5gztwq7Q0ChlAttgG+BMpYOps
> 4H7dO55iz7hZFdYrZlEXBON6VTfQFhnUPuuJHHBRK1E/GEvoA6whRV7bLSrgvtEW
> 6AgFLgb8FWt9mWvf15PAptcvN/AxHGM2ymPyXqh32a+rvfPjdPgFIaCtEQmuGyoV
> NpEwg+iV7TAnEzQ1u0BcOPKr+dKKrkGzahT1Mj1ZFLG0M2J60Hv4oItMXMwvb7vq
> nnubuLwkI8dWdVgmNXIU415i546VoeRuMXY2F7hLEHUKAahcDy5PnmrEj34IVW0w
> qodBW+MeykUA9O+WndUoLI5bTnsGXNS/vZ17LwwcaGyrj2M8bTkqCMvdx8HXGnJ2
> hNN+INazIbIq7FBcQZfEHH1uJsDKy5Niqk3uKysfByyPzehcY6QxseJgqztIRqLR
> HDeymrgOn5k8HRgA4ePKOQwQe2r2vY+3ExydvL7irHMgD7EaSnUIE8KK1Aq39mQz
> ZVWigJGII05HGk/vOQP4s804hjkyS8X+CNXpMzi/2bgmzKp4aPCS1yyx2m+8eP7B
> Qs5h9YxqUh24HC7EGNkx31M4OuL1h1CmkT7uk9uCOREuRnhxClLvTL1Pu8f8OjbN
> jd2W1c/X7spOsvBg7OMD8aBpxI7qWSSWwIe5dsbNbCCDeHkZpJ4GDqxtLLv4+tEO
> XozNTlPhyF0eURRzrVyEL8C5OaSGLEfo3kFCJdS7eQX2TyttILOV9plP4YaFUw91
> DOZj1vjPVgRJSAr98/UlzE23yGfB1gUG/kUG2+HPgu2jS5TE7Mlsk6Wy5Q+3Ga+b
> wD4=
> -----END ENCRYPTED PRIVATE KEY-----
> </private-key-pem>
> <pem>
> -----BEGIN CERTIFICATE-----
> MIIDWTCCAkGgAwIBAgIEQFuxgzANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJD
> WjEXMBUGA1UEBxMOQ3plY2ggUmVwdWJsaWMxDzANBgNVBAsTBkVBUCBRRTEQMA4G
> A1UEChMHUmVkIEhhdDERMA8GA1UEAxMIY2xpZW50RG4wIBcNMTcwNjIwMDYxMzU5
> WhgPMjIxNzA1MDMwNjEzNTlaMFwxCzAJBgNVBAYTAkNaMRcwFQYDVQQHEw5DemVj
> aCBSZXB1YmxpYzEPMA0GA1UECxMGRUFQIFFFMRAwDgYDVQQKEwdSZWQgSGF0MREw
> DwYDVQQDEwhjbGllbnREbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
> AJsXwctr7ckEMiLtsyXaFiSaB03F5z5fVzyg89WMxqWMhfRPitDIFBGN8t3/fEML
> s5I3g1dlQDwtVl9AlwHDLfwxFdLZIuDodRr6KzcTrbavDSRczGMCF+ntPo6KBBL1
> /UZLUW5y332bi7Tkc87NYN9zJ+3307fHrxGmCyeF6as7s/+uKJ0gY4JVjS/9XXec
> K8gtlye/AbBZyJhpPiM71aoQy+LecYdSB/cRBQII0XGtsusguCFGnSSA80J79TLP
> THaJG0trarktvORvnmNQz45Atxhpr9shv4xkbNWHR+qAiFO9N1w7uVFZOZUWEb9/
> bQEFlSo0LtMPgLomKGvg8/0CAwEAAaMhMB8wHQYDVR0OBBYEFO01U/yTywCdzOUl
> hZmElDjVVcZXMA0GCSqGSIb3DQEBCwUAA4IBAQAEy+IphU7QjlWgn2kkKI6RAX6p
> LAWGUlbNnfw7V131of9qz9lctRnFWazbuych/i5/oCvBj+0gyf6+PvpsfB7qlZwH
> 3H+jMNNoCrMp5MutLe9SYcfmvYkYGym77K4e8BiuDlfw3whE4B274nD99Y+e9CcY
> FuUx3yepXY9FDo58mE05zLSXhn31uIulnUGbL1iDB1yeCFG/6J7z+AkCBPKzbgFX
> 3UZid9MUn45RDf8BlP6zG+px/cE2XlaZa+0LGSH9vvvVykD18cthsLHe71Q+Y2hC
> vWvHG8wdujBxWg7A+H38x48i0PR6lNTsjEgTZbUgYM/SQtKvX2gNaR3z2YPU
> -----END CERTIFICATE-----
> </pem>
> </certificate>
> </credentials>
> <providers>
> <use-service-loader/>
> </providers>
> </configuration>
> </authentication-configurations>
> </authentication-client>
> </configuration>
> {code}
> following exception is thrown:
> {code}
> org.wildfly.client.config.ConfigXMLParseException: parser must be on START_ELEMENT to read next text
> at file:/path/to/some/wildfly-config.xml:13:89
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:40)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
> ... 16 more
> Caused by: org.wildfly.client.config.ConfigXMLParseException: parser must be on START_ELEMENT to read next text
> at file:/path/to/some/wildfly-config.xml:13:89
> at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.getElementText(XMLStreamReaderImpl.java:835)
> at org.wildfly.client.config.BasicXMLStreamReader.getElementText(BasicXMLStreamReader.java:87)
> at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getElementText(AbstractDelegatingXMLStreamReader.java:80)
> at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getElementText(AbstractDelegatingXMLStreamReader.java:80)
> at org.wildfly.security.auth.client.ElytronXmlParser.parsePem(ElytronXmlParser.java:1169)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseCertificateType(ElytronXmlParser.java:1116)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseCredentialsType(ElytronXmlParser.java:961)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationConfigurationType(ElytronXmlParser.java:714)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationConfigurationsType(ElytronXmlParser.java:341)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:273)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:185)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:146)
> at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:38)
> ... 18 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JGRP-1440) JDBC_PING java.sql.SQLException: ORA-00001: unique constraint violated
by Matthew Buckett (JIRA)
[ https://issues.jboss.org/browse/JGRP-1440?page=com.atlassian.jira.plugin.... ]
Matthew Buckett commented on JGRP-1440:
---------------------------------------
We're using an old version of jGroups in our project and noticed this problem. Looking at this I think it's because in older versions of jGroups the {{org.jgroups.util.DefaultTimeScheduler}} extended {{java.util.concurrent.ScheduledThreadPoolExecutor}} which didn't block concurrent execution of tasks so it could result that multiple tasks were attempting to update the database table concurrently on the same node.
The newer code in {{org.jgroups.util.TimeScheduler3}} looks to prevent a task being added back onto the queue until it has run so it should prevent local concurrent tasks. So I think the changes added in this issue could be removed.
For our project the simplest fix is to just upgrade the version of jGroups we use.
> JDBC_PING java.sql.SQLException: ORA-00001: unique constraint violated
> ----------------------------------------------------------------------
>
> Key: JGRP-1440
> URL: https://issues.jboss.org/browse/JGRP-1440
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.12.1
> Environment: windows xp, oracle 11G
> Reporter: freeliuade freeliuade
> Assignee: Sanne Grinovero
> Labels: JDBC_PING,
> Fix For: 3.1
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> using JDBC_PING, create a very simple JChannel, unique constraint violated exception will throw sometimes.
> it's a occationally issue. to easy reproduce it, using debug to let threads hold on JDBC_PING.writeToFile(...). line insert(...) (JDBC_PING line 246 in JGroups2.12.1.Final) you can find three threads will be hold on here. then using debug to step over this line, the unique constraint violated exception will throw.
> I uploaded a debug diagram in here http://ww2.sinaimg.cn/mw600/649a9869jw1dr8m399uqdj.jpg
> following is the exception stack:
> SEVERE: Error updating JDBC_PING table
> java.sql.SQLException: ORA-00001: unique constraint (HLIUCLUSTER.SYS_C0038277) violated
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
> at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
> at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:219)
> at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:970)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1190)
> at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3370)
> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3454)
> at org.jgroups.protocols.JDBC_PING.insert(JDBC_PING.java:265)
> at org.jgroups.protocols.JDBC_PING.writeToFile(JDBC_PING.java:246)
> at org.jgroups.protocols.FILE_PING.sendGetMembersRequest(FILE_PING.java:115)
> at org.jgroups.protocols.Discovery$PingSenderTask$1.run(Discovery.java:527)
> at org.jgroups.util.TimeScheduler2$RecurringTask.run(TimeScheduler2.java:592)
> at org.jgroups.util.TimeScheduler2$MyTask.run(TimeScheduler2.java:524)
> at org.jgroups.util.TimeScheduler2$Entry.execute(TimeScheduler2.java:429)
> at org.jgroups.util.TimeScheduler2$1.run(TimeScheduler2.java:295)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
