You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(41) |
May
(353) |
Jun
(133) |
Jul
(534) |
Aug
(401) |
Sep
(219) |
Oct
(86) |
Nov
(144) |
Dec
(61) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(200) |
Feb
(130) |
Mar
(345) |
Apr
(153) |
May
(247) |
Jun
(338) |
Jul
(222) |
Aug
(70) |
Sep
(39) |
Oct
(27) |
Nov
(76) |
Dec
(30) |
2007 |
Jan
(81) |
Feb
(44) |
Mar
(9) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(34) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(6) |
2008 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Matthew B. <mat...@ou...> - 2006-07-24 08:52:12
|
Alistair Young wrote: > oh dear, I've just started on a HelloWorldFacility with javadocs and > full documentation before it morphs into a chat tool. So a Facility > is registered (hard coded) into Resource? hmmm A resource has a HttpFacilityUINumber which then gets mapped to a facility. The mapping from the number can be changed at deploy time through the Bodington properties file. > I need an id for it. The first free one we have here is 301. This be > ok for everyone else? or is that taken in other versions of bod? We don't have 301 in use. > Or is this not a good way to choose? Seems there are random numbers > all over the shop. There was some plan whereby each major partner would have a chunk of the Facility numbers but I can't remember which chunks we all got. http://sourceforge.net/mailarchive/message.php?msg_id=12464769 Seems to indicate Oxford would use 101-200 and UHI would use 201-300. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
From: Matthew B. <mat...@ou...> - 2006-07-24 08:47:05
|
Alistair Young wrote: > This is just a wee Q about spring and when it might go into head on > sourceforge. We see spring as freeing bod development from the > templates and opening up new avenues of exploration into ELF land. I'd like to get some feedback and put it into Bodington HEAD soon. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
From: Paul D. <pau...@ou...> - 2006-07-23 11:01:15
|
Will this be under the new licence regime? I hope so Paul Trafford has succesfully negotiated a stand at Educause in October so be good to go with OSSwatch backing Paul ----- Original Message ----- From: "Sean Mehan" <se...@sm...> To: "Bodington developers" <Bod...@li...> Sent: Friday, July 21, 2006 4:41 PM Subject: [Bodington-developers] Freeze of head for Tuesday > Bodders, > > In anticipation of a 2.8 release, is it possible to commit last bits > and bobs to head by Tuesday, 25/7, 15:00. I will then make a release > of 2.8 with a branch on Wed. > > Is this agreeable? > > -s > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > > |
From: Sean M. <se...@sm...> - 2006-07-21 15:42:41
|
A plan! Can we get some discussion going of how to get the jsp / spring stuff from Weblearn head into Bod head asap after the weblearn release on 15/8? Discuss! s |
From: Sean M. <se...@sm...> - 2006-07-21 15:41:37
|
Bodders, In anticipation of a 2.8 release, is it possible to commit last bits and bobs to head by Tuesday, 25/7, 15:00. I will then make a release of 2.8 with a branch on Wed. Is this agreeable? -s |
From: Alistair Y. <ali...@sm...> - 2006-07-21 14:26:22
|
oh dear, I've just started on a HelloWorldFacility with javadocs and full documentation before it morphs into a chat tool. So a Facility is registered (hard coded) into Resource? hmmm I need an id for it. The first free one we have here is 301. This be ok for everyone else? or is that taken in other versions of bod? Or is this not a good way to choose? Seems there are random numbers all over the shop. Alistair |
From: Alistair Y. <ali...@sm...> - 2006-07-21 12:17:23
|
it's broken again |
From: Alistair Y. <ali...@sm...> - 2006-07-21 08:35:27
|
This is just a wee Q about spring and when it might go into head on sourceforge. We see spring as freeing bod development from the templates and opening up new avenues of exploration into ELF land. ta, Alistair |
From: Matthew B. <mat...@ou...> - 2006-07-20 13:45:21
|
Peter Crowther wrote: >> From: Matthew Buckett >> Then all the outputted date selection boxes have an extra class added: >> >> <input type=text name=test class=datetime> >> >> which means that they then get the calendar widget added. > > Note that this will interact poorly with my mods in 2.8 that add a time > field. You may wish to see whether the fix is as simple as altering > what's emitted in Facility::outputDateInput - you might just have to add > "class=datetime" to the attributes of the date box for it to Just Work. That should work as the calendar widget does both date and time. If you add just class=date then you can't select the time I think. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
From: Peter C. <Pet...@me...> - 2006-07-20 13:25:01
|
> From: Matthew Buckett > Then all the outputted date selection boxes have an extra class added: >=20 > <input type=3Dtext name=3Dtest class=3Ddatetime> >=20 > which means that they then get the calendar widget added. Note that this will interact poorly with my mods in 2.8 that add a time field. You may wish to see whether the fix is as simple as altering what's emitted in Facility::outputDateInput - you might just have to add "class=3Ddatetime" to the attributes of the date box for it to Just = Work. - Peter |
From: Matthew B. <mat...@ou...> - 2006-07-20 13:16:19
|
Naomi Miles wrote: > Cheers Matthew, can you narrow down the haystack and point me in the > direction of where (template?) you use it please? calendar.js calendar-en.js calendar.css utils.js has been modified. Then all the outputted date selection boxes have an extra class added: <input type=text name=test class=datetime> which means that they then get the calendar widget added. -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
From: Naomi M. <na...@sm...> - 2006-07-20 13:03:34
|
Cheers Matthew, can you narrow down the haystack and point me in the direction of where (template?) you use it please? Ta, Naomi. On 20 Jul 2006, at 11:52, Matthew Buckett wrote: > Naomi Miles wrote: >> Hi all >> >> Does bod use a datepicker anywhere? I've had a little look, but >> don't see one. I need one and thought I'd ask before I go >> downloading huge js files. BTW, if you happen to have any personal >> recommendations (about datepickers) , don't hesitate to pass them on. > > WebLearn has a datepicker but this hasn't been merged onto > Bodington. It > is planned to go on. > > I ended up using: > > http://www.dynarch.com/projects/calendar > > It is added to all calendar fields. You should be able to grab a > demo of > it working from: > > http://dev.weblearn.ox.ac.uk/cruisecontrol/artifacts/weblearn/ > 20060720114414 > > -- > -- Matthew Buckett, VLE Developer > -- Learning Technologies Group, Oxford University Computing Services > -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: Matthew B. <mat...@ou...> - 2006-07-20 10:52:50
|
Naomi Miles wrote: > Hi all > > Does bod use a datepicker anywhere? I've had a little look, but > don't see one. I need one and thought I'd ask before I go > downloading huge js files. BTW, if you happen to have any personal > recommendations (about datepickers) , don't hesitate to pass them on. WebLearn has a datepicker but this hasn't been merged onto Bodington. It is planned to go on. I ended up using: http://www.dynarch.com/projects/calendar It is added to all calendar fields. You should be able to grab a demo of it working from: http://dev.weblearn.ox.ac.uk/cruisecontrol/artifacts/weblearn/20060720114414 -- -- Matthew Buckett, VLE Developer -- Learning Technologies Group, Oxford University Computing Services -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/ |
From: Naomi M. <na...@sm...> - 2006-07-20 10:46:57
|
Hi all Does bod use a datepicker anywhere? I've had a little look, but don't see one. I need one and thought I'd ask before I go downloading huge js files. BTW, if you happen to have any personal recommendations (about datepickers) , don't hesitate to pass them on. Cheers, Naomi. |
From: Alistair Y. <ali...@sm...> - 2006-07-19 19:02:51
|
The load balancing will be handy - never got round to that. Why not do an LDAP bean or something and stick ones for each server in the context, wit= h maybe an LDAPManager or something to decide which beans can be used for authentication, based on round robin-ing and past performance? authenticate() can then get a reliable bean from the manager and delegate authentication to it. If you'd like me to help out just shout. About time I did some more work on it. I think it's been in there for a couple of years without modification. One thing that definitely needs tidied up is the group matching (staff or student) - I think it's very uhi-centric at the moment! --=20 Alistair Young Senior Software Engineer UHI@Sabhal M=F2r Ostaig Isle of Skye Scotland > Peter Crowther wrote: >>> From: Jon Maber >>> if you resolve a host name it doesn't take any longer >>> to get all the IP numbers - a single response packet lists >>> them all. (In >>> fact a suspect that the same call is made and that the Java >>> method that fetches one IP number just discards the others.) >>> >> >> Memory says you're right, and that a DNS client RFC-SHOULD contact the >> addresses in order - so the call that returns a single address should >> return the first one. However, I'm doing this from memory without the >> spec in front of me. >> >> >>> I don't think that the >>> Leeds DNS is clever enough to change the order of the IP >>> numbers so I've >>> implemented a cycle in the authenticator that balances the load. >>> >> >> Makes sense. I assume you also refuse to contact failed servers for a >> period after detecting the failure? >> > I haven't done that bit yet. That might be an eleventh hour activity..= .. > > > > -----------------------------------------------------------------------= -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers > |
From: Jon M. <jo...@te...> - 2006-07-19 17:27:56
|
Peter Crowther wrote: >> From: Jon Maber >> if you resolve a host name it doesn't take any longer >> to get all the IP numbers - a single response packet lists >> them all. (In >> fact a suspect that the same call is made and that the Java >> method that fetches one IP number just discards the others.) >> > > Memory says you're right, and that a DNS client RFC-SHOULD contact the > addresses in order - so the call that returns a single address should > return the first one. However, I'm doing this from memory without the > spec in front of me. > > >> I don't think that the >> Leeds DNS is clever enough to change the order of the IP >> numbers so I've >> implemented a cycle in the authenticator that balances the load. >> > > Makes sense. I assume you also refuse to contact failed servers for a > period after detecting the failure? > I haven't done that bit yet. That might be an eleventh hour activity.... |
From: Peter C. <Pet...@me...> - 2006-07-19 16:13:41
|
> From: Jon Maber > if you resolve a host name it doesn't take any longer=20 > to get all the IP numbers - a single response packet lists=20 > them all. (In=20 > fact a suspect that the same call is made and that the Java=20 > method that fetches one IP number just discards the others.) Memory says you're right, and that a DNS client RFC-SHOULD contact the addresses in order - so the call that returns a single address should return the first one. However, I'm doing this from memory without the spec in front of me. > I don't think that the=20 > Leeds DNS is clever enough to change the order of the IP=20 > numbers so I've=20 > implemented a cycle in the authenticator that balances the load. Makes sense. I assume you also refuse to contact failed servers for a period after detecting the failure? - Peter |
From: Jon M. <jo...@te...> - 2006-07-19 15:01:15
|
Alistair Young wrote: > ah, ok, that makes sense. The current one just polls based on what it > finds in the xml conf file. Are you suggesting it should further > expand it's list by finding out if any of those servers are dns round- > robins? Should make it an option rather than hard wired as some sites > dns resolving is insanely slow. > I assume that if you use a numerical host that will avoid the DNS lookup. However, if you resolve a host name it doesn't take any longer to get all the IP numbers - a single response packet lists them all. (In fact a suspect that the same call is made and that the Java method that fetches one IP number just discards the others.) I don't think that the Leeds DNS is clever enough to change the order of the IP numbers so I've implemented a cycle in the authenticator that balances the load. Jon |
From: Alistair Y. <ali...@sm...> - 2006-07-19 14:45:29
|
ah, ok, that makes sense. The current one just polls based on what it finds in the xml conf file. Are you suggesting it should further expand it's list by finding out if any of those servers are dns round- robins? Should make it an option rather than hard wired as some sites dns resolving is insanely slow. Alistair On 19 Jul 2006, at 15:08, Jon Maber wrote: > >> Seriously, if you've only got until Saturday why worry about sockets? >> The LDAP server should have a default idle timeout that would cover >> in the first instance. >> > It's sorted - quite easy really. I'll explain why it's important - > Leeds has about 8 different servers whose IP numbers are all mapped > to a > single DNS name. Any server can be brought down for maintenance at > any > time. So, I've added code that resolves the complete list of IP > numbers > against the configured ldap server name. It then cycles around them > until a connection is made. (Also does some load balancing.) If a > server is running but not accepting connections on the ldap port the > attempt to connect fails immediately but if the server is not > running at > all the timeout is several minutes. This is a pointless delay if > there > are other LDAP servers ready and waiting. > > Anyway it was quite easy to implement. > > Jon > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: Jon M. <jo...@te...> - 2006-07-19 14:08:13
|
> Seriously, if you've only got until Saturday why worry about sockets? > The LDAP server should have a default idle timeout that would cover > in the first instance. > It's sorted - quite easy really. I'll explain why it's important - Leeds has about 8 different servers whose IP numbers are all mapped to a single DNS name. Any server can be brought down for maintenance at any time. So, I've added code that resolves the complete list of IP numbers against the configured ldap server name. It then cycles around them until a connection is made. (Also does some load balancing.) If a server is running but not accepting connections on the ldap port the attempt to connect fails immediately but if the server is not running at all the timeout is several minutes. This is a pointless delay if there are other LDAP servers ready and waiting. Anyway it was quite easy to implement. Jon |
From: Alistair Y. <ali...@sm...> - 2006-07-19 13:23:01
|
> Alistair[weird] = Jon[Ingenious] I can hear your trumpet from here Jon ;) I suspect any potential bugs are either due to only UHI using it so we don't know what other setups there are or the incredible ingenuity of the interface simply overwhelming a mere mortal such as myself ;) > It has to be deployed on Saturday my sympathies > It > initially has some hard wired extras which eventually lead to new VLEs! > whether the user is a student > or staff yes, that's a point - that will never be interoperable. That's what shibboleth is designed for. It makes it easier to map attributes such as this to groups etc. > I think I found another way to make it work using a custom > socket factory genius, pure genious. I have visions of you being carried through the streets of Leeds in a sedan chair, lightly wafted by ostrich feathers, flinging scraps of scribbled arcana to the crowds. When's the film? Seriously, if you've only got until Saturday why worry about sockets? The LDAP server should have a default idle timeout that would cover in the first instance. Alistair On 19 Jul 2006, at 14:01, Jon Maber wrote: > Alistair Young wrote: >>> If credentials are set then valid is set false ... set valid=true >>> when the authentication failed >>> >> this kind of weirdness! >> > Alistair[weird] = Jon[Ingenious] ;-) >> >>> eventually I'll generalise it and commit >>> back to the release version >>> >> can you not generalise it from the start? > Two reasons not to - 1) It has to be deployed on Saturday. 2) It > initially has some hard wired extras, i.e. whether the user is a > student > or staff is found by looking at the length of an attribute in the LDAP > record and because I'm not 100% confident about the user names > currently > in the Bodington database always corresponding to the user names in > the > LDAP extra checks are made - payroll number and student number must > match. So, before it replaces the current authenticator it needs > these > kinds of things separated out and I don't have time to do it now. > > Another problem - the nice constructor with the timeout option doesn't > do what I thought it would! The number is used to set the socket data > reading timeout which is not the same as the socket connection > timeout. > However, I think I found another way to make it work using a custom > socket factory. > > Jon > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: Jon M. <jo...@te...> - 2006-07-19 13:01:36
|
Alistair Young wrote: >> If credentials are set then valid is set false ... set valid=true >> when the authentication failed >> > this kind of weirdness! > Alistair[weird] = Jon[Ingenious] ;-) > >> eventually I'll generalise it and commit >> back to the release version >> > can you not generalise it from the start? Two reasons not to - 1) It has to be deployed on Saturday. 2) It initially has some hard wired extras, i.e. whether the user is a student or staff is found by looking at the length of an attribute in the LDAP record and because I'm not 100% confident about the user names currently in the Bodington database always corresponding to the user names in the LDAP extra checks are made - payroll number and student number must match. So, before it replaces the current authenticator it needs these kinds of things separated out and I don't have time to do it now. Another problem - the nice constructor with the timeout option doesn't do what I thought it would! The number is used to set the socket data reading timeout which is not the same as the socket connection timeout. However, I think I found another way to make it work using a custom socket factory. Jon |
From: Alistair Y. <ali...@sm...> - 2006-07-19 11:54:54
|
> Actually it is a problem in the Authenticator yes, I suspected as much. The way bod "authenticates" is a bit weird and I obviously hadn't fully grasped that weirdness > If credentials are set then valid is set false ... set valid=true > when the authentication failed this kind of weirdness! > eventually I'll generalise it and commit > back to the release version can you not generalise it from the start? you'll have to let us test it here before you commit. We also need the auto creation so that can't be removed. We also need the Alias handling to speed up searching for users, i.e. where it stores your DN as an Alias for you in the db. Finding it in bod is quicker than trawling an enterprise system. One cleanup thing that needs done is loading the XML conf file from the CLASSPATH. It uses getBodingtonRoot() just now but some versions of BuildingServer don't have it. What I definitely want to avoidi is site specific LDAPAuthenticator. Basically, everything that's in the curent LDAPAuthenticator has to be in the "Leeds specific" one if it's going into head. Alistair On 19 Jul 2006, at 12:31, Jon Maber wrote: > Alistair Young wrote: >> Hi Jon, hopefully I can answer your questions: >> > Thanks. I had found the API docs but somehow overlooked that alternate > constructor - I was looking in the LDAPConstraints class. Looks > like I > can do what I want with the OpenLDAP API so there's no real argument > left for switching. >> There are a few things to consider when doing LDAP "authentication". >> Bod always calls the LDAPAuthenticator no matter what page you're >> viewing. This has led to problems here and at Leeds I beilieve. >> >> I also haven't ruled out something wrong in the ldap code! haven't >> had time to look at it. >> > Actually it is a problem in the Authenticator. Bodington repeatedly > calls the isAuthenticated() method to allow an authenticator to > time out > an authentication session if it wants. However, there is > absolutely no > need to repeatedly bind to the LDAP server every time that > isAuthenticated is called. You can see the basic pattern in the plain > password authenticator - the 'valid' variable is used to prevent > repeated authentication. If credentials are set then valid is set > false > to indicate that the class doesn't know if the user is > authenticated or > not. If the authenticator is asked if the user is authenticated and > valid is false then it calls the private authenticate method, > otherwise > if valid is true it just gives the stored result. > > Your code was failing to set valid=true when the authentication failed > which was forcing the LDAP connection to be repeated over and over. > I've fixed it (and a number of other potential bugs) in the custom > authenticator I'm creating and eventually I'll generalise it and > commit > back to the release version (2.10?). > > Thanks Alistair. > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |
From: Jon M. <jo...@te...> - 2006-07-19 11:31:54
|
Alistair Young wrote: > Hi Jon, hopefully I can answer your questions: > Thanks. I had found the API docs but somehow overlooked that alternate constructor - I was looking in the LDAPConstraints class. Looks like I can do what I want with the OpenLDAP API so there's no real argument left for switching. > There are a few things to consider when doing LDAP "authentication". > Bod always calls the LDAPAuthenticator no matter what page you're > viewing. This has led to problems here and at Leeds I beilieve. > > I also haven't ruled out something wrong in the ldap code! haven't > had time to look at it. > Actually it is a problem in the Authenticator. Bodington repeatedly calls the isAuthenticated() method to allow an authenticator to time out an authentication session if it wants. However, there is absolutely no need to repeatedly bind to the LDAP server every time that isAuthenticated is called. You can see the basic pattern in the plain password authenticator - the 'valid' variable is used to prevent repeated authentication. If credentials are set then valid is set false to indicate that the class doesn't know if the user is authenticated or not. If the authenticator is asked if the user is authenticated and valid is false then it calls the private authenticate method, otherwise if valid is true it just gives the stored result. Your code was failing to set valid=true when the authentication failed which was forcing the LDAP connection to be repeated over and over. I've fixed it (and a number of other potential bugs) in the custom authenticator I'm creating and eventually I'll generalise it and commit back to the release version (2.10?). Thanks Alistair. |
From: Alistair Y. <ali...@sm...> - 2006-07-19 10:49:19
|
Hi Jon, hopefully I can answer your questions: > I'm trying to set a custom timeout on the connection Novell added a new LDAPConnection constructor: http://developer.novell.com/documentation/jldap/jldapenu/api/index.html > The Sun LDAP service provider has a connection pooling option. Is > there anything equivalent in the Open LDAP API? http://developer.novell.com/documentation/jldap/jldapenu/api/index.html > What was the reason for choosing the OpenLDAP API instead of JNDI? I'd been doing a lot of LDAP work with eDirectory (creating accounts etc) and so had a load of experience with it. The openLDAP Java classes were originally devleoped by Novell and they donated them to openLDAP.org so it seemed logical to keep using them for bod LDAP. JNDI is much more abstract. LDAPAuthenticator will only ever authenticate against an LDAP server. It doesn't need that abstraction. Also, I find Sun stuff ropey or bloated sometimes, that's just my opinion. The Novell openLDAP libs were ideal and they have a C version too. At the time I was looking at LDAPing RADIUS so having the same framework for Java and C made sense. > Is > there a strong argument against switching to JNDI? for me, no. LDAP is LDAP. JNDI is at a higher level of abstraction. It's also persona non grata in ActiveDirectory. I had a lot of problems creating accounts in ActiveDirectory using JNDI. There was a Microsoft report that JNDI had problems connecting/binding to AD servers. In this respect, openLDAP was more successful. Also, the openLDAP code works against slapd/eDirectory/ ActiveDirectory (all tested). As we may need to support AD in the future, JNDI has already proved itself less than useful. There are a few things to consider when doing LDAP "authentication". Bod always calls the LDAPAuthenticator no matter what page you're viewing. This has led to problems here and at Leeds I beilieve. When you enter an incorrect password, you get sent to the failure page, which causes bod to call the authenticator, which fails again, then you go to the login page, another login failure and finally back to the page with the login boxes, another auth failure. So that's 3 auth failures as bod keeps calling LDAPAuthenticator with bum credentials. This eventually locks a user out of their LDAP server. This only happens as the authentictator is doing a bind to prove the credentials. You could do a compare on the password but this might not be interoperable and might not be supported by the schema in use. Bind will always work though. Also, binding causes a login event on the LDAP server and that can keep over zealous admins from deleting what they think are expired accounts. e.g. we have people who never log in to eDirectory and they login to CLAN all the time. Doing a compare on their password instead of a bind would show them as *never* logging in to eDir and the admins trawl and delete such accounts now and again. I also haven't ruled out something wrong in the ldap code! haven't had time to look at it. Alistair On 19 Jul 2006, at 11:04, Jon Maber wrote: > Probably one for Alistair... > > I'm working on a customised LDAP authenticator for Leeds. > > The standard authenticator uses the OpenLDAP Java API instead of JNDI > and the Sun LDAP service provider. I started off also using the > OpenLDAP API but I've got stuck on a couple of things. > > 1) I'm trying to set a custom timeout on the connection to the LDAP > socket. (I want it to be much shorter than the default) However, I > can't > see a mechanism for changing the timeout. I've worked out how to > adjust > the timeout on searches etc. but not the timeout on socket > connections. > Any ideas? > > 2) The Sun LDAP service provider has a connection pooling option. Is > there anything equivalent in the Open LDAP API? > > What was the reason for choosing the OpenLDAP API instead of JNDI? Is > there a strong argument against switching to JNDI? > > Jon > > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Bodington-developers mailing list > Bod...@li... > https://lists.sourceforge.net/lists/listinfo/bodington-developers |