[JBoss JIRA] (WFLY-7322) LDAP referrals does not work in Elytron ldap-realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.... ]
Jan Kalina resolved WFLY-7322.
------------------------------
Resolution: Done
> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
> Key: WFLY-7322
> URL: https://issues.jboss.org/browse/WFLY-7322
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 11.0.0.Alpha1
>
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFLY-4539) logging statement to trace remoting heartbeat
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.... ]
Peter Palaga commented on WFLY-4539:
------------------------------------
[~dmlloyd] on one hand the downstream BZ asks for (1) "the option to log on the client when the heartbeat message is *fired*", which we indeed do not provide, but on the other hand we provide (2) an option on both server and client to log when a heartbeat message is *received*.
>From the downstream BZ steps to reproduce it is clear that they do not know about (2), because they activate wrong log level (DEBUG instead of TRACE) for an improper topic (org.jboss.remoting3 instead of org.jboss.remoting.remote, org.jboss.remoting.remote.client, org.jboss.remoting.remote.connection and org.jboss.remoting.remote.server).
regardless if (2) would serve their purpose, it is easy to add (1) and I am ready to send a PR unless you want to veto it for some reason?
> logging statement to trace remoting heartbeat
> ---------------------------------------------
>
> Key: WFLY-4539
> URL: https://issues.jboss.org/browse/WFLY-4539
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Carsten Lichy-Bittendorf
> Assignee: Peter Palaga
> Priority: Minor
>
> you can set the heartbeat on a remoting connection by setting:
> remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL
> What is missing is the option to log on the client when the heartbeat message is fired.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFLY-7705) LdapRealm - referral mode: direct verification + THROW mode
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7705?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7705:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> LdapRealm - referral mode: direct verification + THROW mode
> ------------------------------------------------------------
>
> Key: WFLY-7705
> URL: https://issues.jboss.org/browse/WFLY-7705
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Fix For: 11.0.0.Alpha1
>
>
> *1) Log in as referral user is still not possible.*
> Currently referral user can be found by ldap realm, but his password cannot be verified => log in is still not possible.
> There are two possible ways how to authenticate user in ldap realm:
> using direct verification - in this case after obtaining referral user, this referral user is used in LDAP bindRequest against original LDAP server (not referenced LDAP server) which results to invalid credentials bindResponse
> not using direct verification - in this case after obtaining referral user, this user is used as part of baseObject scope LDAP searchRequest for password attribute against original LDAP server (not referenced LDAP server) which results to noSuchObject searchResDone.
> Comment [1] says that you are able to log in as user of referred server. Can you please share your configuration? Since there is no related documentation, maybe I do something wrong in using/not using of direct verification.
> *2) Elytron does not handle THROW referral mode*
> In case when dir-context uses THROW referral-mode then com.sun.jndi.ldap.LdapReferralException is not caught in Elytron (which is LDAP client) and is thrown to integration tier which also does not handle it, e.g. in case when ldap-realm is used for authentication to application, then it results to status code 500 returned to the application.
> [1] https://issues.jboss.org/browse/WFLY-7322?focusedCommentId=13307815&page=...
> ( Requested in https://issues.jboss.org/browse/JBEAP-6450?focusedCommentId=13323387#comm... )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFLY-7705) LdapRealm - referral mode: direct verification + THROW mode
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7705?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7705:
-----------------------------------
Priority: Major (was: Blocker)
> LdapRealm - referral mode: direct verification + THROW mode
> ------------------------------------------------------------
>
> Key: WFLY-7705
> URL: https://issues.jboss.org/browse/WFLY-7705
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Fix For: 11.0.0.Alpha1
>
>
> *1) Log in as referral user is still not possible.*
> Currently referral user can be found by ldap realm, but his password cannot be verified => log in is still not possible.
> There are two possible ways how to authenticate user in ldap realm:
> using direct verification - in this case after obtaining referral user, this referral user is used in LDAP bindRequest against original LDAP server (not referenced LDAP server) which results to invalid credentials bindResponse
> not using direct verification - in this case after obtaining referral user, this user is used as part of baseObject scope LDAP searchRequest for password attribute against original LDAP server (not referenced LDAP server) which results to noSuchObject searchResDone.
> Comment [1] says that you are able to log in as user of referred server. Can you please share your configuration? Since there is no related documentation, maybe I do something wrong in using/not using of direct verification.
> *2) Elytron does not handle THROW referral mode*
> In case when dir-context uses THROW referral-mode then com.sun.jndi.ldap.LdapReferralException is not caught in Elytron (which is LDAP client) and is thrown to integration tier which also does not handle it, e.g. in case when ldap-realm is used for authentication to application, then it results to status code 500 returned to the application.
> [1] https://issues.jboss.org/browse/WFLY-7322?focusedCommentId=13307815&page=...
> ( Requested in https://issues.jboss.org/browse/JBEAP-6450?focusedCommentId=13323387#comm... )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFLY-7763) "Unable to find unambiguous method" when overriding a generic method that has more than one parameter
by Tobias Liefke (JIRA)
[ https://issues.jboss.org/browse/WFLY-7763?page=com.atlassian.jira.plugin.... ]
Tobias Liefke commented on WFLY-7763:
-------------------------------------
I have to admin, I don't know if this is the correct place to report that type of problem.
My clue was, that the problematic class {{javax.el.Util}} can be found in {{jboss-el-api_3.0_spec-1.0.7.Final.jar}} and that WFLY-3456 reports already a similar (fixed) problem.
> "Unable to find unambiguous method" when overriding a generic method that has more than one parameter
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-7763
> URL: https://issues.jboss.org/browse/WFLY-7763
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 10.1.0.Final
> Reporter: Tobias Liefke
> Assignee: Farah Juma
>
> I've written a generic typed class, which is extended by a class which binds the type variable:
> {code:java}
> public abstract class AppendableController<A extends Appendable> {
> public String append(A appendable, Number number) {
> // ...
> }
> }
> @Named
> public class WriterController extends AppendableController<Writer> {
> @Override
> public String append(Writer writer, Number number) {
> //....
> }
> public Writer getWriter() {
> return new StringWriter();
> }
> public Writer getNoWriter() {
> return null;
> }
> }
> {code}
> If I reference the {{append}} method in an JSF expression, I found many cases where this will result in an _MethodNotFoundException_ with the message:
> {code}Unable to find unambiguous method{code}
> Examples:
> * Case 1: {{writerController.append(writerController.writer, 1)}} -> _Unable to find unambiguous method: WriterController.append(java.io.StringWriter, java.lang.Long)_
> * Case 2: {{writerController.append(writerController.noWriter, 1)}} -> _Unable to find unambiguous method: class org.example.WriterController.append(null, java.lang.Long)_
> The reason is that {{WriterController.class.getMethods()}} returns both methods {{AppendableController.append(Appendable, Number)}} and {{WriterController.append(Writer, Number)}}.
> I see two problems here:
> * The type of the parameter is not derived from the type of the parameter expression. This will lead to non-deterministic behavior of the expression. Either because there are optional parameters, which might be null (see case 2), or parameters are sometimes proxied resp. extensions of the parameter type (see case 1).
> * In truth there is nothing unambiguous in this example, because both methods map to the same method invocation of the overridden method, no matter which I would call. It would be safe to call either of them.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFLY-7763) "Unable to find unambiguous method" when overriding a generic method that has more than one parameter
by Tobias Liefke (JIRA)
[ https://issues.jboss.org/browse/WFLY-7763?page=com.atlassian.jira.plugin.... ]
Tobias Liefke updated WFLY-7763:
--------------------------------
Description:
I've written a generic typed class, which is extended by a class which binds the type variable:
{code:java}
public abstract class AppendableController<A extends Appendable> {
public String append(A appendable, Number number) {
// ...
}
}
@Named
public class WriterController extends AppendableController<Writer> {
@Override
public String append(Writer writer, Number number) {
//....
}
public Writer getWriter() {
return new StringWriter();
}
public Writer getNoWriter() {
return null;
}
}
{code}
If I reference the {{append}} method in an JSF expression, I found many cases where this will result in an _MethodNotFoundException_ with the message:
{code}Unable to find unambiguous method{code}
Examples:
* Case 1: {{writerController.append(writerController.writer, 1)}} -> _Unable to find unambiguous method: WriterController.append(java.io.StringWriter, java.lang.Long)_
* Case 2: {{writerController.append(writerController.noWriter, 1)}} -> _Unable to find unambiguous method: class org.example.WriterController.append(null, java.lang.Long)_
The reason is that {{WriterController.class.getMethods()}} returns both methods {{AppendableController.append(Appendable, Number)}} and {{WriterController.append(Writer, Number)}}.
I see two problems here:
* The type of the parameter is not derived from the type of the parameter expression. This will lead to non-deterministic behavior of the expression. Either because there are optional parameters, which might be null (see case 2), or parameters are sometimes proxied resp. extensions of the parameter type (see case 1).
* In truth there is nothing unambiguous in this example, because both methods map to the same method invocation of the overridden method, no matter which I would call. It would be safe to call either of them.
was:
I've written a generic typed class, which is extended by a class which binds the type variable:
{code:java}
public abstract class AppendableController<A extends Appendable> {
public String append(A appendable, Number number) {
// ...
}
}
@Named
public class WriterController extends AppendableController<Writer> {
@Override
public String append(Writer writer, Number number) {
//....
}
public Writer getWriter() {
return new StringWriter();
}
public Writer getNoWriter() {
return null;
}
}
{code}
If I reference the {{append}} method in an JSF expression, I found many cases where this will result in an _MethodNotFoundException_ with the message:
{code}Unable to find unambiguous method{code}
Examples:
* Case 1: {{writerController.append(writerController.writer, 1)}} -> _Unable to find unambiguous method: WriterController.append(java.io.StringWriter, java.lang.Long)_
* Case 2: {{writerController.append(writerController.noWriter, 1)}} -> _Unable to find unambiguous method: class org.example.WriterController.append(null, java.lang.Long)_
The reason is that {{WriterController.class.getMethods()}} returns both methods {{AppendableController.append(Appendable, Number)}} and {{WriterController.append(Writer, Number)}}.
I see two problems here:
* The type of the parameter is not derived from the type of the parameter expression. This will lead to non-deterministic behavior of the expression. Either because there are optional parameters, which might be null (see case 2), or parameters are sometimes proxied resp. extensions of the parameter type.
2. In truth there is nothing unambiguous in this example, because both methods map to the same method invocation of the overridden method, no matter which I would call. It would be safe to call either of them.
> "Unable to find unambiguous method" when overriding a generic method that has more than one parameter
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-7763
> URL: https://issues.jboss.org/browse/WFLY-7763
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 10.1.0.Final
> Reporter: Tobias Liefke
> Assignee: Farah Juma
>
> I've written a generic typed class, which is extended by a class which binds the type variable:
> {code:java}
> public abstract class AppendableController<A extends Appendable> {
> public String append(A appendable, Number number) {
> // ...
> }
> }
> @Named
> public class WriterController extends AppendableController<Writer> {
> @Override
> public String append(Writer writer, Number number) {
> //....
> }
> public Writer getWriter() {
> return new StringWriter();
> }
> public Writer getNoWriter() {
> return null;
> }
> }
> {code}
> If I reference the {{append}} method in an JSF expression, I found many cases where this will result in an _MethodNotFoundException_ with the message:
> {code}Unable to find unambiguous method{code}
> Examples:
> * Case 1: {{writerController.append(writerController.writer, 1)}} -> _Unable to find unambiguous method: WriterController.append(java.io.StringWriter, java.lang.Long)_
> * Case 2: {{writerController.append(writerController.noWriter, 1)}} -> _Unable to find unambiguous method: class org.example.WriterController.append(null, java.lang.Long)_
> The reason is that {{WriterController.class.getMethods()}} returns both methods {{AppendableController.append(Appendable, Number)}} and {{WriterController.append(Writer, Number)}}.
> I see two problems here:
> * The type of the parameter is not derived from the type of the parameter expression. This will lead to non-deterministic behavior of the expression. Either because there are optional parameters, which might be null (see case 2), or parameters are sometimes proxied resp. extensions of the parameter type (see case 1).
> * In truth there is nothing unambiguous in this example, because both methods map to the same method invocation of the overridden method, no matter which I would call. It would be safe to call either of them.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFLY-7763) "Unable to find unambiguous method" when overriding a generic method that has more than one parameter
by Tobias Liefke (JIRA)
Tobias Liefke created WFLY-7763:
-----------------------------------
Summary: "Unable to find unambiguous method" when overriding a generic method that has more than one parameter
Key: WFLY-7763
URL: https://issues.jboss.org/browse/WFLY-7763
Project: WildFly
Issue Type: Bug
Components: JSF
Affects Versions: 10.1.0.Final
Reporter: Tobias Liefke
Assignee: Farah Juma
I've written a generic typed class, which is extended by a class which binds the type variable:
{code:java}
public abstract class AppendableController<A extends Appendable> {
public String append(A appendable, Number number) {
// ...
}
}
@Named
public class WriterController extends AppendableController<Writer> {
@Override
public String append(Writer writer, Number number) {
//....
}
public Writer getWriter() {
return new StringWriter();
}
public Writer getNoWriter() {
return null;
}
}
{code}
If I reference the {{append}} method in an JSF expression, I found many cases where this will result in an _MethodNotFoundException_ with the message:
{code}Unable to find unambiguous method{code}
Examples:
* Case 1: {{writerController.append(writerController.writer, 1)}} -> _Unable to find unambiguous method: WriterController.append(java.io.StringWriter, java.lang.Long)_
* Case 2: {{writerController.append(writerController.noWriter, 1)}} -> _Unable to find unambiguous method: class org.example.WriterController.append(null, java.lang.Long)_
The reason is that {{WriterController.class.getMethods()}} returns both methods {{AppendableController.append(Appendable, Number)}} and {{WriterController.append(Writer, Number)}}.
I see two problems here:
* The type of the parameter is not derived from the type of the parameter expression. This will lead to non-deterministic behavior of the expression. Either because there are optional parameters, which might be null (see case 2), or parameters are sometimes proxied resp. extensions of the parameter type.
2. In truth there is nothing unambiguous in this example, because both methods map to the same method invocation of the overridden method, no matter which I would call. It would be safe to call either of them.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months