[jira] [Created] (DIRAPI-298) Inconsistent SASL bind API

[Emmanuel Lecharny (JIRA)]

Emmanuel Lecharny created DIRAPI-298:


 Summary: Inconsistent SASL bind API
 Key: DIRAPI-298
 URL: https://issues.apache.org/jira/browse/DIRAPI-298
 Project: Directory Client API
  Issue Type: Improvement
Reporter: Emmanuel Lecharny


We do have the following bind methods in {{LdapConnection}} :

* {{void anonymousBind()}}
* {{void bind()}}
* {{void bind( String name )}}
* {{void bind( String name, String credentials )}}
* {{void bind( Dn name )}}
* {{void bind( Dn name, String credentials )}}
* {{BindResponse bind( BindRequest bindRequest )}}

That does not cover any of the SASL binds.

However, in the {{LdapNetworkConnection}}/{{AbstractLdapConnection}} 
implementation, we have the following SASL bind mehods :

* {{void bind()}}
* {{void bind( String name )}} (abstract)
* {{void bind( String name, String credentials )}} (abstract)
* {{void bind( Dn name )}} (abstract)
* {{void bind( Dn name, String credentials )}} (abstract)
* {{void anonymousBind()}}
* {{BindResponse bind( BindRequest bindRequest )}}
* {{BindResponse bind( SaslCramMd5Request request )}}
* {{BindResponse bind( SaslDigestMd5Request request )}}
* {{BindResponse bind( SaslGssApiRequest request )}}

As we can see, we have dedicated methods for some of the SASL binds, but the 
SASL PLAIN ([https://docs.ldap.com/specs/rfc4616.txt]) and SASL ANONYMOUS 
([https://docs.ldap.com/specs/rfc4616.txt]) are not present. 

The {{bindSaslPlain}} method is commented in the interface.

At this point, we probably have to implement the missing PLAIN and ANONYMOUS 
SASL bind methods, expose them in the interface, and probably add a {{bindSasl( 
SaslRequest )}} method to cover all our bases




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (DIRKRB-638) KerbyGssAppTest fails when there is no keytab on the service side

[Colm O hEigeartaigh (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRKRB-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112573#comment-16112573
 ] 

Colm O hEigeartaigh edited comment on DIRKRB-638 at 8/3/17 11:10 AM:
-

Thanks [~jiajia], that looks good to me. Will you commit the patches? I will do 
some minor changes when they are applied - we should still use the kvno for the 
keytab case, but not for the Subject case.


was (Author: coheigea):
Thanks [~jiajia], that looks good to me. Will you commit the patches? I will do 
some minor changes when they are applied.

> KerbyGssAppTest fails when there is no keytab on the service side
> -
>
> Key: DIRKRB-638
> URL: https://issues.apache.org/jira/browse/DIRKRB-638
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: DIRKRB-638.patch, DIRKRB-638-V2.patch
>
>
> When we log in via a username/password on the service side, as opposed to a 
> keytab, the KerbyGssAppTest does not work, as GssAcceptCred is only written 
> to handle keytabs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DIRKRB-638) KerbyGssAppTest fails when there is no keytab on the service side

[Colm O hEigeartaigh (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRKRB-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112573#comment-16112573
 ] 

Colm O hEigeartaigh commented on DIRKRB-638:


Thanks [~jiajia], that looks good to me. Will you commit the patches? I will do 
some minor changes when they are applied.

> KerbyGssAppTest fails when there is no keytab on the service side
> -
>
> Key: DIRKRB-638
> URL: https://issues.apache.org/jira/browse/DIRKRB-638
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: DIRKRB-638.patch, DIRKRB-638-V2.patch
>
>
> When we log in via a username/password on the service side, as opposed to a 
> keytab, the KerbyGssAppTest does not work, as GssAcceptCred is only written 
> to handle keytabs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Access LDAPmessage

[Dineth Chalitha Basnayaka]

Hi all,

Is there way to access client's LDAPmessage at the server side.

Thanks,
Dineth.



[image: dinethr.PNG]

Dineth Chalitha Basnayake.

Undergraduate in Computer Science & Technology,

Uva Wellassa University of Sri Lanka

dinethchali...@gmail.com

[image: facebook.png] [image:
Linked in alt.png]
[image:
github.png] 

Re: Access LDAPmessage

[Emmanuel Lécharny]

Le 03/08/2017 à 18:11, Dineth Chalitha Basnayaka a écrit :
> Hi all,
>
> Is there way to access client's LDAPmessage at the server side.

Yes. Now the question is : where do you want to get the LdapMessage from
? Ie, are you implementing your own intecreptor, for instance ?

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Access LDAPmessage

[Dineth Chalitha Basnayaka]

Yes. I'am trying to do capture LDAPmessage at server side and map it
message elements to java objects.



[image: dinethr.PNG]

Dineth Chalitha Basnayake.

Undergraduate in Computer Science & Technology,

Uva Wellassa University of Sri Lanka

dinethchali...@gmail.com

[image: facebook.png] [image:
Linked in alt.png]
[image:
github.png] 

On Thu, Aug 3, 2017 at 10:06 PM, Emmanuel Lécharny 
wrote:

>
>
> Le 03/08/2017 à 18:11, Dineth Chalitha Basnayaka a écrit :
> > Hi all,
> >
> > Is there way to access client's LDAPmessage at the server side.
>
> Yes. Now the question is : where do you want to get the LdapMessage from
> ? Ie, are you implementing your own intecreptor, for instance ?
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>

Re: Ldap API 2.0 roadmap

[Emmanuel Lécharny]

Le 03/08/2017 à 18:43, Radovan Semancik a écrit :
> On 08/03/2017 02:03 PM, Emmanuel Lécharny wrote:
>> We have released the Apache LDAP API 1.0 a few weeks ago. This was a
>> great acomplishment, after years of efforts. It was not perfect, but
>> still, 'good enough' is probably the correct description.
>
> I would say this is more than a correct observation :-)
>
>> ... So let's thing bigger : If we go for a 2.0, I also suggest we
>> move to
>> Java 8 only for this version (I mean, Java 8 and higher). ApacheDS will
>> also switch to Java 8 and will use this API 2.0 in M25, and teh next
>> Studio release should also use the API 2.0 and ApacheDS with API 2.0.
>
> I completely support this proposal.
>
>> I would also suggest we switch to git for the API, now that 1.0 is out.
>> SVN is outdated, and it's quite an anchor for us anyway (I have to use
>> svn *and* git daily, it makes things more complex...). Nor sure we
>> should'nt move to git for all teh projects, but startng wih teh API
>> sounds reasonable atm. In any case, I'll write another mail for this
>> change.
>
> Yes, yes, yes! Then sooner the better.
>
> I have few more things to add:
>
> I would like to personally work on the schema error handling and
> reporting. The API currently logs every schema problem as an error -
> even if it can live with the situation. This is really annoying when
> using the API with dirty LDAP servers. The logs are flooded with error
> messages and there is no easy way how to get rid of them. So I would
> like to improve this part of code and make error reporting
> optional/configurable/pluggable.
>
> But ... it is likely that any reasonable changes in the code are going
> to break compatibility with API 1.0. Unless we want to maintain very
> ugly and complex compatibility code. Therefore I suggest that we do
> NOT stick to a strict API compatibility between 1.0 and 2.0. This is
> not a problem for me, as I can quickly adapt my client application.
> But I'm aware that it might be a problem for other people. Therefore I
> would like to know opinions of the community regarding API 1.0->2.0
> compatibility.

2.0 is not guarentiing an API compatibility with 1.0. However, I think
we ought to write down a migration guide.

So I think we can bork everything we want, up to a point of course.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Access LDAPmessage

[Emmanuel Lécharny]

Le 03/08/2017 à 18:56, Dineth Chalitha Basnayaka a écrit :
> Yes. I'am trying to do capture LDAPmessage at server side and map it
> message elements to java objects.

I need to now exactly where in the server you want to have access to the
LdapMessage in order to give you some information on how to access this
data structure.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Access LDAPmessage

[Dineth Chalitha Basnayaka]

When I am going to access AddRequest message, I want access that message
when its come to AddRequestDecorator class in ldap server. Is it possible?



[image: dinethr.PNG]

Dineth Chalitha Basnayake.

Undergraduate in Computer Science & Technology,

Uva Wellassa University of Sri Lanka

dinethchali...@gmail.com

[image: facebook.png] [image:
Linked in alt.png]
[image:
github.png] 

On Thu, Aug 3, 2017 at 10:37 PM, Emmanuel Lécharny 
wrote:

>
>
> Le 03/08/2017 à 18:56, Dineth Chalitha Basnayaka a écrit :
> > Yes. I'am trying to do capture LDAPmessage at server side and map it
> > message elements to java objects.
>
> I need to now exactly where in the server you want to have access to the
> LdapMessage in order to give you some information on how to access this
> data structure.
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>

Re: Ldap API 2.0 roadmap

[Radovan Semancik]

On 08/03/2017 02:03 PM, Emmanuel Lécharny wrote:

We have released the Apache LDAP API 1.0 a few weeks ago. This was a
great acomplishment, after years of efforts. It was not perfect, but
still, 'good enough' is probably the correct description.


I would say this is more than a correct observation :-)


... So let's thing bigger : If we go for a 2.0, I also suggest we move to
Java 8 only for this version (I mean, Java 8 and higher). ApacheDS will
also switch to Java 8 and will use this API 2.0 in M25, and teh next
Studio release should also use the API 2.0 and ApacheDS with API 2.0.


I completely support this proposal.


I would also suggest we switch to git for the API, now that 1.0 is out.
SVN is outdated, and it's quite an anchor for us anyway (I have to use
svn *and* git daily, it makes things more complex...). Nor sure we
should'nt move to git for all teh projects, but startng wih teh API
sounds reasonable atm. In any case, I'll write another mail for this change.


Yes, yes, yes! Then sooner the better.

I have few more things to add:

I would like to personally work on the schema error handling and 
reporting. The API currently logs every schema problem as an error - 
even if it can live with the situation. This is really annoying when 
using the API with dirty LDAP servers. The logs are flooded with error 
messages and there is no easy way how to get rid of them. So I would 
like to improve this part of code and make error reporting 
optional/configurable/pluggable.


But ... it is likely that any reasonable changes in the code are going 
to break compatibility with API 1.0. Unless we want to maintain very 
ugly and complex compatibility code. Therefore I suggest that we do NOT 
stick to a strict API compatibility between 1.0 and 2.0. This is not a 
problem for me, as I can quickly adapt my client application. But I'm 
aware that it might be a problem for other people. Therefore I would 
like to know opinions of the community regarding API 1.0->2.0 compatibility.


--
Radovan Semancik
Software Architect
evolveum.com

Re: Access LDAPmessage

[Emmanuel Lécharny]

Le 03/08/2017 à 19:34, Dineth Chalitha Basnayaka a écrit :
> When I am going to access AddRequest message, I want access that message
> when its come to AddRequestDecorator class in ldap server. Is it possible?

Again, you are not precise enough. AddRequestDecorator is an LDAP API
class, it does not belong to the server.

I need to know *where in the server* you want to access teh AddRequest
message.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Access LDAPmessage

[Dineth Chalitha Basnayaka]

Can you give what are the possible places in ldap server I can access that
message.

Thanks.



[image: dinethr.PNG]

Dineth Chalitha Basnayake.

Undergraduate in Computer Science & Technology,

Uva Wellassa University of Sri Lanka

dinethchali...@gmail.com

[image: facebook.png] [image:
Linked in alt.png]
[image:
github.png] 

On Fri, Aug 4, 2017 at 1:45 AM, Emmanuel Lécharny 
wrote:

>
>
> Le 03/08/2017 à 19:34, Dineth Chalitha Basnayaka a écrit :
> > When I am going to access AddRequest message, I want access that message
> > when its come to AddRequestDecorator class in ldap server. Is it
> possible?
>
> Again, you are not precise enough. AddRequestDecorator is an LDAP API
> class, it does not belong to the server.
>
> I need to know *where in the server* you want to access teh AddRequest
> message.
>
> --
> Emmanuel Lecharny
>
> Symas.com
> directory.apache.org
>
>

[jira] [Updated] (DIRKRB-642) Remove the bytes util functions in GssTokenBase

[Lin Zeng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRKRB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lin Zeng updated DIRKRB-642:

Attachment: DIRKRB-642-01.patch

initial patch attatched:

# remove the bytes util functions in GssTokenBase, and correponding usage 
replaced by the BytesUtil.
# Now that the bytes util funtions removed, which are the main part of 
GssTokenBase, I remove the GssTokenBase class.

> Remove the bytes util functions in GssTokenBase
> ---
>
> Key: DIRKRB-642
> URL: https://issues.apache.org/jira/browse/DIRKRB-642
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Jiajia Li
>Assignee: Lin Zeng
> Attachments: DIRKRB-642-01.patch
>
>
> BytesUtil has the same functions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DIRKRB-642) Remove the bytes util functions in GssTokenBase

[Jiajia Li (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRKRB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16113853#comment-16113853
 ] 

Jiajia Li commented on DIRKRB-642:
--

I think we can leave the GssTokenBase there.

> Remove the bytes util functions in GssTokenBase
> ---
>
> Key: DIRKRB-642
> URL: https://issues.apache.org/jira/browse/DIRKRB-642
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Jiajia Li
>Assignee: Lin Zeng
> Attachments: DIRKRB-642-01.patch
>
>
> BytesUtil has the same functions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Access LDAPmessage

[Emmanuel Lécharny]

Le 04/08/2017 à 05:32, Dineth Chalitha Basnayaka a écrit :
> Can you give what are the possible places in ldap server I can access that
> message.

http://www.catb.org/esr/faqs/smart-questions.html#explicit

In other word, ApacheDS is a 200 000 lines of code project. Im not going
to go throught it to show you how to get the information you need, it
would simply take me days. Either you tell me where in the code you want
to access LDAPMessage, or you are totally on your own.


Thanks.

Re: Ldap API 2.0 roadmap

[Stefan Seelmann]

+1 just move forward.

The only thought I have is to do a Studio release with current ApacheDS
and API version, I wanted to do since weeks it but didn't find the time
and won't have time in the next 2 weeks either.

Kind Regards,
Stefan


On 08/03/2017 02:03 PM, Emmanuel Lécharny wrote:
> Hi guys,
> 
> 
> I didn't had time last week-end to post this mail.
> 
> We have released the Apache LDAP API 1.0 a few weeks ago. This was a
> great acomplishment, after years of efforts. It was not perfect, but
> still, 'good enough' is probably the correct description.
> 
> 
> Beside this effort, I started to work on a branch
> (http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
> which was a refactoring of the Value class, in order to simplify what we
> had in 1.0. The rational was to get some major errors being fixed in
> ApacheDS (mainly related to some special chars being mis-handled in
> DNs). The consequences are huge in term of performances (20% faster),
> but impacts the projects using this API.
> 
> 
> At this point, I'd like to suggest we start with a 2.0 because of those
> API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
> the branch, and I also have a branch for Apacheds which relies on the
> API branch. What remains to be done is to switch to this branch for Studio.
> 
> 
> So let's thing bigger : If we go for a 2.0, I also suggest we move to
> Java 8 only for this version (I mean, Java 8 and higher). ApacheDS will
> also switch to Java 8 and will use this API 2.0 in M25, and teh next
> Studio release should also use the API 2.0 and ApacheDS with API 2.0.
> 
> 
> I would also suggest we switch to git for the API, now that 1.0 is out.
> SVN is outdated, and it's quite an anchor for us anyway (I have to use
> svn *and* git daily, it makes things more complex...). Nor sure we
> should'nt move to git for all teh projects, but startng wih teh API
> sounds reasonable atm. In any case, I'll write another mail for this change.
> 
> 
> I'd like to have your opinion about those proposed changes, before
> starting an official vote.
> 
> 
> Many thanks !
> 
> 

Re: Ldap API 2.0 roadmap

[Emmanuel Lécharny]

Le 04/08/2017 à 07:03, Stefan Seelmann a écrit :
> +1 just move forward.
>
> The only thought I have is to do a Studio release with current ApacheDS
> and API version, I wanted to do since weeks it but didn't find the time
> and won't have time in the next 2 weeks either.

I can create a branch for Studio supporting the new API and ApacheDS
version, that would make sense.

Whenever you are ready for a release of Studio is fine. In any case, the
studio branch I would create won't be ready in the  next two weeks ;-)


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Ldap API 2.0 roadmap

[Emmanuel Lécharny]

Le 03/08/2017 à 15:05, Shawn McKinney a écrit :
>
>> On Aug 3, 2017, at 7:03 AM, Emmanuel Lécharny  wrote:
>>
>>
>> Beside this effort, I started to work on a branch
>> (http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
>> which was a refactoring of the Value class, in order to simplify what we
>> had in 1.0. The rational was to get some major errors being fixed in
>> ApacheDS (mainly related to some special chars being mis-handled in
>> DNs). The consequences are huge in term of performances (20% faster),
>> but impacts the projects using this API.
>>
>>
>> At this point, I'd like to suggest we start with a 2.0 because of those
>> API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
>> the branch, and I also have a branch for Apacheds which relies on the
>> API branch. What remains to be done is to switch to this branch for Studio.
>>
>> So let's thing bigger : If we go for a 2.0, I also suggest we move to
>> Java 8 only for this version (I mean, Java 8 and higher). ApacheDS will
>> also switch to Java 8 and will use this API 2.0 in M25, and teh next
>> Studio release should also use the API 2.0 and ApacheDS with API 2.0.
>>
>> I would also suggest we switch to git for the API, now that 1.0 is out.
>> SVN is outdated, and it's quite an anchor for us anyway (I have to use
>> svn *and* git daily, it makes things more complex...). Nor sure we
>> should'nt move to git for all teh projects, but startng wih teh API
>> sounds reasonable atm. In any case, I'll write another mail for this change.
>>
>> I'd like to have your opinion about those proposed changes, before
>> starting an official vote.
>>
> Seems a little strange to have a 2.0 this close to a 1.0 release but in the 
> end the version doesn’t matter all that much.  The main thing is we keep 
> forward progress so…

Well, I think it conveys a message : it's alive ! Once upon a time, OSS
was very conservative, and projects were moving from X to X+1 with
extreme caution (httpd, etc). Then Chrome changed the game with its fast
incremental version releases, and Fireforx followd, and now, many other
projects do the same.

I do think it's easier for people to follow up when the major is
changing rather than going on with somethig that remains teh same for
years...

But that may be just me.

Otherwise, considering teh API changes, we can't make it a minor (ie
1.1), so 2.0 is quite necesary.

Btw, 1.0 will be maintained, so we are likey to have a 1.0.1 and some
other versions later o (with Java 7 support, of course).

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Ldap API 2.0 roadmap

[Shawn McKinney]

> On Aug 3, 2017, at 7:03 AM, Emmanuel Lécharny  wrote:
> 
> I didn't had time last week-end to post this mail.
> 
> We have released the Apache LDAP API 1.0 a few weeks ago. This was a
> great acomplishment, after years of efforts. It was not perfect, but
> still, 'good enough' is probably the correct description.

No it’s not perfect but what software library is?  It’s a very good and stable 
API that is approaching 1M downloads a month via maven, meaning it has 
traction.  

Congrats on getting it this far.

> 
> Beside this effort, I started to work on a branch
> (http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
> which was a refactoring of the Value class, in order to simplify what we
> had in 1.0. The rational was to get some major errors being fixed in
> ApacheDS (mainly related to some special chars being mis-handled in
> DNs). The consequences are huge in term of performances (20% faster),
> but impacts the projects using this API.
> 
> 
> At this point, I'd like to suggest we start with a 2.0 because of those
> API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
> the branch, and I also have a branch for Apacheds which relies on the
> API branch. What remains to be done is to switch to this branch for Studio.
> 
> So let's thing bigger : If we go for a 2.0, I also suggest we move to
> Java 8 only for this version (I mean, Java 8 and higher). ApacheDS will
> also switch to Java 8 and will use this API 2.0 in M25, and teh next
> Studio release should also use the API 2.0 and ApacheDS with API 2.0.
> 
> I would also suggest we switch to git for the API, now that 1.0 is out.
> SVN is outdated, and it's quite an anchor for us anyway (I have to use
> svn *and* git daily, it makes things more complex...). Nor sure we
> should'nt move to git for all teh projects, but startng wih teh API
> sounds reasonable atm. In any case, I'll write another mail for this change.
> 
> I'd like to have your opinion about those proposed changes, before
> starting an official vote.
> 

Seems a little strange to have a 2.0 this close to a 1.0 release but in the end 
the version doesn’t matter all that much.  The main thing is we keep forward 
progress so…

+1 on that, move to Java 8 and GIT.

Thanks,
Shawn

[jira] [Resolved] (DIRKRB-638) KerbyGssAppTest fails when there is no keytab on the service side

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRKRB-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh resolved DIRKRB-638.

Resolution: Fixed

> KerbyGssAppTest fails when there is no keytab on the service side
> -
>
> Key: DIRKRB-638
> URL: https://issues.apache.org/jira/browse/DIRKRB-638
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: DIRKRB-638.patch, DIRKRB-638-V2.patch
>
>
> When we log in via a username/password on the service side, as opposed to a 
> keytab, the KerbyGssAppTest does not work, as GssAcceptCred is only written 
> to handle keytabs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DIRKRB-638) KerbyGssAppTest fails when there is no keytab on the service side

[Jiajia Li (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRKRB-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112685#comment-16112685
 ] 

Jiajia Li commented on DIRKRB-638:
--

I committed.

commit ea45cc80f175a0d1292dbb4bfa69f75bba78b35b
Author: plusplusjiajia 
Date:   Thu Aug 3 21:06:11 2017 +0800  
Get the KerberosKey from Subject as the server key.

> KerbyGssAppTest fails when there is no keytab on the service side
> -
>
> Key: DIRKRB-638
> URL: https://issues.apache.org/jira/browse/DIRKRB-638
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: DIRKRB-638.patch, DIRKRB-638-V2.patch
>
>
> When we log in via a username/password on the service side, as opposed to a 
> keytab, the KerbyGssAppTest does not work, as GssAcceptCred is only written 
> to handle keytabs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Ldap API 2.0 roadmap

[Emmanuel Lécharny]

Hi guys,


I didn't had time last week-end to post this mail.

We have released the Apache LDAP API 1.0 a few weeks ago. This was a
great acomplishment, after years of efforts. It was not perfect, but
still, 'good enough' is probably the correct description.


Beside this effort, I started to work on a branch
(http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
which was a refactoring of the Value class, in order to simplify what we
had in 1.0. The rational was to get some major errors being fixed in
ApacheDS (mainly related to some special chars being mis-handled in
DNs). The consequences are huge in term of performances (20% faster),
but impacts the projects using this API.


At this point, I'd like to suggest we start with a 2.0 because of those
API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
the branch, and I also have a branch for Apacheds which relies on the
API branch. What remains to be done is to switch to this branch for Studio.


So let's thing bigger : If we go for a 2.0, I also suggest we move to
Java 8 only for this version (I mean, Java 8 and higher). ApacheDS will
also switch to Java 8 and will use this API 2.0 in M25, and teh next
Studio release should also use the API 2.0 and ApacheDS with API 2.0.


I would also suggest we switch to git for the API, now that 1.0 is out.
SVN is outdated, and it's quite an anchor for us anyway (I have to use
svn *and* git daily, it makes things more complex...). Nor sure we
should'nt move to git for all teh projects, but startng wih teh API
sounds reasonable atm. In any case, I'll write another mail for this change.


I'd like to have your opinion about those proposed changes, before
starting an official vote.


Many thanks !


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Ldap API 2.0 roadmap

[Zheng, Kai]

Sounds exciting and great move! Any more legacy to get rid of by the chance?

Sent from iPhone

> 在 2017年8月3日，20:04，Emmanuel Lécharny  写道：
> 
> Hi guys,
> 
> 
> I didn't had time last week-end to post this mail.
> 
> We have released the Apache LDAP API 1.0 a few weeks ago. This was a
> great acomplishment, after years of efforts. It was not perfect, but
> still, 'good enough' is probably the correct description.
> 
> 
> Beside this effort, I started to work on a branch
> (http://svn.apache.org/viewvc/directory/shared/branches/shared-value/)
> which was a refactoring of the Value class, in order to simplify what we
> had in 1.0. The rational was to get some major errors being fixed in
> ApacheDS (mainly related to some special chars being mis-handled in
> DNs). The consequences are huge in term of performances (20% faster),
> but impacts the projects using this API.
> 
> 
> At this point, I'd like to suggest we start with a 2.0 because of those
> API changes. FTR, I ave carrefully ported all the changes made in 1.0 to
> the branch, and I also have a branch for Apacheds which relies on the
> API branch. What remains to be done is to switch to this branch for Studio.
> 
> 
> So let's thing bigger : If we go for a 2.0, I also suggest we move to
> Java 8 only for this version (I mean, Java 8 and higher). ApacheDS will
> also switch to Java 8 and will use this API 2.0 in M25, and teh next
> Studio release should also use the API 2.0 and ApacheDS with API 2.0.
> 
> 
> I would also suggest we switch to git for the API, now that 1.0 is out.
> SVN is outdated, and it's quite an anchor for us anyway (I have to use
> svn *and* git daily, it makes things more complex...). Nor sure we
> should'nt move to git for all teh projects, but startng wih teh API
> sounds reasonable atm. In any case, I'll write another mail for this change.
> 
> 
> I'd like to have your opinion about those proposed changes, before
> starting an official vote.
> 
> 
> Many thanks !
> 
> 
> -- 
> Emmanuel Lecharny
> 
> Symas.com
> directory.apache.org
> 

[jira] [Commented] (DIRKRB-638) KerbyGssAppTest fails when there is no keytab on the service side

[Jiajia Li (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRKRB-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112629#comment-16112629
 ] 

Jiajia Li commented on DIRKRB-638:
--

[~coheig], my patch based on your patch, so can you help me to commit it with 
your patch? Thanks.

> KerbyGssAppTest fails when there is no keytab on the service side
> -
>
> Key: DIRKRB-638
> URL: https://issues.apache.org/jira/browse/DIRKRB-638
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: DIRKRB-638.patch, DIRKRB-638-V2.patch
>
>
> When we log in via a username/password on the service side, as opposed to a 
> keytab, the KerbyGssAppTest does not work, as GssAcceptCred is only written 
> to handle keytabs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DIRKRB-638) KerbyGssAppTest fails when there is no keytab on the service side

[Colm O hEigeartaigh (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRKRB-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112661#comment-16112661
 ] 

Colm O hEigeartaigh commented on DIRKRB-638:


OK I applied my patch.

> KerbyGssAppTest fails when there is no keytab on the service side
> -
>
> Key: DIRKRB-638
> URL: https://issues.apache.org/jira/browse/DIRKRB-638
> Project: Directory Kerberos
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: DIRKRB-638.patch, DIRKRB-638-V2.patch
>
>
> When we log in via a username/password on the service side, as opposed to a 
> keytab, the KerbyGssAppTest does not work, as GssAcceptCred is only written 
> to handle keytabs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)