Re: Non-web .jsp templates ?
Why not user Velocity? It is already set up to do this, and even has an ant task (Texen) to help automate it. Jim --- Deacon Marcus <[EMAIL PROTECTED]> wrote: > Hi, > Our team was recently discussing potential usage of > .jsp pages as templates > for use with automatic mail generation and other > automated tasks when the > result is not sent via http but stored and/or > processed. Are there any > (open-source preffered) projects (taglibs?) with > similar goals? If not, do > you think it's something with enough demand to > release it when it's > late-beta? > The discussed approach was to include a jsp-template > inside of a custom tag > redirecting it to a specified e-mail address/list on > an itermediate (process > and forward type) jsp page. > > Greetings, deacon Marcus > __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Re: [PROPOSAL] Standalone SSL
--- Christopher Cain <[EMAIL PROTECTED]> wrote: > > In short, it is currently a needless exposure, and > certs are much more > important than most other resources. If I paid good > money for a real > cert signed by a CA, I would especially have a > comprehensive security > scheme in place to protect it. Leaving the password > sitting around would > be about the last thing I would possibly do. If your > box is compromised, > then your cert store is also unquestionably > compromised. If your store > is compromised, than every cert and private key in > that store is > worthless. That could potentially be catastrophic in > a business > environment, and would leave you open to all kinds > nasty things. If > someone gets ahold of your cert, bad, bad, BAD > things can happen. Just > ask Microsoft =) > > And if you should be cracked, and someone > masqaurades as you to do bad > things, that is a lawsuit you will not win because > you did not have take > resonable precautions against it. I realize that > this is all a bit of > Chicken Little-ism, but my point is that SSL > implementation is a serious > business. And I can choose to lock down the rest of > the stuff you > mention with a custom solution. I have no such > option with the SSL > implemention (short of hacking the code, which we > can't reasonably > expect people to have to do). > One of the possible custom solutons is to encrypt the other information with your public key, then use the private key to decrypt the other sensitive information. Since the info is signed with the public key, any developer could encrypt information that could only be retrieved by the system. That way, the solution would scale. Anyway, if you implement the "prompt for key on reboot" it could always be a configurable option, so if someone didn't feel that level of security was necessary, they wouldn't have to use it. Jim __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Re: [PROPOSAL] Standalone SSL
--- "Pier P. Fumagalli" <[EMAIL PROTECTED]> wrote: > Jim Seach at [EMAIL PROTECTED] wrote: > > > > One of the possible custom solutons is to encrypt the > > other information with your public key, then use the > > private key to decrypt the other sensitive > > information. > > Cool, are we going to use a private key to encrypt the password for > the > private key of Tomcat? Cool, kinda gets recursive... :) WHAT? > > Pier > That would be a good trick! :) What I meant was, in order to implement SSL, Tomcat must be able to decrypt the keystore to retrieve the private key for the cert. A Tomcat extension or module could be developed to use the private key not only to decode the SSL traffic, but also to decode other information like database passwords and so forth that developers wished to securely make available to Tomcat. (How to make this information available to the webapp code would have to be carefully designed) If Christopher's suggestion about prompting for the keystore key is implemented, none of these private pieces of information need to be stored in plaintext. Jim __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Re: [PROPOSAL] Standalone SSL
--- Christopher Cain <[EMAIL PROTECTED]> wrote: > > > The system would still have to have access to the private key, which > would have to be protected with some kind of PBE scheme, in which > case > you are right back to specifying a password in the config files. > > Aside from that, it's not really a "custom" solution in the sense > that I > can implement it without hacking Tomcat. Any possible solution to not > storing the password in the clear will require a custom build of > Tomcat, > which is really one of my points. One can work around the other > security > issues without resorting to that. I am going to have to hack a more > secure solution into Tomcat at this point regardless. My hope is that > we > can come to some kind of consensus on the best way to lock the SSL > keystore down so that I can contribute the code back to the product. > IMHO, the current solution is a rather big hole waiting to be > exploited > and needs addressing anywy, at least in a business production > environment. I agree, this could be done now, since the keystore password is in the config file, but my assumption was that it is not worth going through the additional effort to secure the other information unless your proposal were implemented. At that point, it might be worth it to develop a standard (carefully designed) way to store other information in order to get around Craig's scalability concerns. > > > Anyway, if you implement the "prompt for key on > > reboot" it could always be a configurable option, so > > if someone didn't feel that level of security was > > necessary, they wouldn't have to use it. > > Excellent idea! Configurable is good =) I wouldn't mind at all adding > that in during my rework, assuming everyone agrees that it makes > sense > (and that my basic patches are accepted anyway, of course :-) > > - Christopher Jim __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Re: [PROPOSAL] Standalone SSL
--- Christopher Cain <[EMAIL PROTECTED]> wrote: > [SNIP] > Again, I haven't looked at the > Realm stuff and what-not, but I can't imagine the possible risk being > nearly as devestating. I'm not trying to toot my own horn or talk > about > how great I am, but security/crypto is my area of expertise, so > really > hope I am believed when I say that having your certs so easily > accessible is an absolute disaster waiting to happen ... much more so > than any of the other system resource stuff. > > As to your point, I would agree that if one is not worried about the > security of their certs, they are probably not too worried about the > rest. If you're going to address overall resource security, the certs > are unquestionably the place to start, IMO. I see it as a problem > which > requires immediate addressing. Since I secure my own database access > stuff, and I don't use realms or LDAP or any other stuff like that, I > can't really speak to the relative risk there. > > > At that point, it might be worth it to develop a standard > (carefully > > designed) way to store other information in order to get around > Craig's > > scalability concerns. > > I think that makes sense. It would be nice to have a well-designed > "External Resource Security" module that could be seemlessly plugged > in > and handle all of it from a single point. And I this would make > Costin > proud, but if possible I would to do such a thing in the commons so > that > multiple contains could benefit from it. I'd have to sit down and > examine the feasibility of such a thing of course, WRT any security > functionality that we would be foregoing by maintaining JDK 1.1 > compatibility, but it's a nice idea (at least in my opinion ... I'm > not > sure what the general sentiment is). I would even be willing to > spearhead such a thing. I know, I know, I've also agreed to help out > with any Jikes API project, but I didn't necessarily agree to > SPEARHEAD > that :-) > > In any event, I would still like to see the (at least configurable) > "prompt me" approach in the CVS tree ASAP for two reasons. First, I > think it would be nice to get the option out there for the more > security-sensitive standalone installs immediately. Second, even with > a > centralized external security solution, we are still going to have to > get around the "initial authentication" problem anyway, and I really > can't see a better method than command-line prompt (unless I am > missing > something). There's just no killer way around not storing passwords > in > the clear. Once I have this inital keystore issue resolved (on my end > at > the very least :-), I'd be more than happy to call for a vote on a > centralized solution, at which point we could weigh using my existing > prompt solution for initial authentication. > > - Christopher I think we're in agreement. The "initial authentication" problem needs to be resolved before we can talk about leveraging it to solve the other problems. I like your proposal of an optional prompt solution for this. This is an area of interest for me, but it is not something I spend a large part of my time on, so despite being a CISSP, I am certainly not an expert. I am willing to lend a hand, though, if you are interested in spearheading a general solution to the larger problem. Jim __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Re: [PROPOSAL] Standalone SSL
--- [EMAIL PROTECTED] wrote: > On Tue, 31 Jul 2001, Jim Seach wrote: > > > What I meant was, in order to implement SSL, Tomcat must be able > to > > decrypt the keystore to retrieve the private key for the cert. A > > Tomcat extension or module could be developed to use the private > key > > not only to decode the SSL traffic, but also to decode other > > information like database passwords and so forth that developers > wished > > In particular the admin and/or ajp password :-) > > One of the biggest problems is that so many people are installing > tomcat > and they just forget to change the passwords. > > We already generate a random number for the shutdown command, but a > module > that checks if the admin password is still "changethis" and refuse to > start until the user types a better password will do a lot for > secuirty > :-) > > I'm not very sure about certificate passwords or other things - but > if > someone needs this then great. I think ( IMHO ) the authentication, > etc > should happen outside tomcat ( at least in a different process ), I'm > not > sure if existing auth servers ( kerberos, tacacs, radius, etc ) have > any > support for certificates, but as long as tomcat is running user code > ( > even with the security manager in place ), I wouldn't trust it more > than I > have to. > > And don't forget that tomcat may even crash, or hung ( well, if not > tomcat It has never crashed on me, except where it was clearly my fault! :) > maybe some user code or even the JDK or OS ). :-) > > Costin > I think these are important features/requirements for the "External Resource Security/Centralized Repository" project that Christopher would like to pursue, but was waiting for an expression of interest from the committers. Can this be construed as the expression of interest he was looking for? :) Jim __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Re: Addition of 'dirty' field to Session interface
--- Vishy Kasar <[EMAIL PROTECTED]> wrote:
> Hi,
>
> In order to support persistent failover, we have written our own
> Store
> class that writes session data to DB of our choice. We decided to use
> maxIdleBackups as that will save the data periodically to disk
> without
> getting rid of it in memory.
> PersistentManagerBase.processMaxIdleBackups() writes the session data
> to
> DB at periodical intervals irrespective of session has changed or
> not.
> I think it will be very valuable addition to add getDirty() and
> setDirty(boolean) methods to the Session interface. When
Wouldn't this require a change to the Servlet API? This is probably
not the right list for that :)
> PersistentManagerBase saves the session contents, it can set dirty
> bit
> to false and from then onwards save the session only if the bit is
> set
> to true.
>
> Selected setXXX methods in StandardSession will set the dirty bit to
> true indicating that Session data has changed and it needs to be
> saved
> in the next save cycle by PersistentManager.
But what happens if in one servlet you put an object in the session,
then later, after the session has been saved, another request is
handled by a different servlet that get's the object from the session
and changes its state.
In this case, you have to have the cooperation of the application
developer to call setDirty(true) so you know something has changed.
If you are going to rely on developers following some kind of
convention, it could probably be done without changes to the spec.
What about asking them to call setAttribute("Dirty","True") whenever
they make a change? Your PersistentManager could then remove the
attribute after a save. (not that I believe they would do this
consistently any more than they will call setDirty(true) )
Is there something I am missing?
Jim
>
> Let me know what you guys think of this useful optimization. I can
> contribute the code if necessary.
>
> --
> Cheers!
>
>
>
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: New SSL HOWTOs
--- Christopher Cain <[EMAIL PROTECTED]> wrote:
> While creating the 3.3 version of my SSL HOWTO, I also polished off
> the
> wording here and there and added a TOC and section marks for easier
> navigation. Attached are both the 3.3 and 4.0 versions of the file.
> Consider this 4.0 version to supercede the one I sent last night (or
> early this morning, as it were :-)
>
> If someone could please let me know for sure that adding extension
> JARs
> to the "{JDK_HOME}/jre/lib/ext" directory under JDK 1.1.8 effectively
> makes them "installed extensions" (makes them available without
> necessarily being in the CLASSPATH) just like in >= JDK 1.2. Other
> than
> that, I'm pretty sure the TC 3.3 version of the doc is valid for JDK
> 1.1.8 environments as well. If someone a little more familiar with
> 1.1.8
> could maybe give it a quick once-over and see if anything jumps out,
> that would be great.
>
> - Christopher>
>Tomcat 4.0 Standalone - SSL Configuration
Thanks!
I tried out your quickstart instructions with JDK 1.3 and Tomcat 3.2.3
on Windows 98 and it worked like a charm. The background and detail
sections are well written and contain valuable information.
Nice Job!
Jim
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
RE: KPMG-2002003: Bea Weblogic DOS-device Denial of Service
I found this at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fsys_7qwj.asp The following reserved words cannot be used as the name of a file: CON, PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also, reserved words followed by an extensionfor example, NUL.tx7are invalid file names. And unfortunately, I also found this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/filesio_697p.asp Platform SDK: File Storage DefineDosDevice The DefineDosDevice function defines, redefines, or deletes MS-DOS device names. BOOL DefineDosDevice( DWORD dwFlags, // options LPCTSTR lpDeviceName, // device name LPCTSTR lpTargetPath // path string ); It looks like you can create your own device names, so just keeping a list of the standard ones won't work in all cases. Hope this helps, Jim Seach --- Larry Isaacs <[EMAIL PROTECTED]> wrote: > I was too optimistic after testing only with Win98. I get the same > problem with Win2k. > > As you have probably already discovered, FileUtil.savePath() blocks > the attempt to read > aux.jsp. So getting past the version file safely should be > sufficient. Updating the mangler > looks like it would work, though the fix is only as good as our list > of DOS devices. > I'm aware of: > > CON > NUL > COM1-COM9 > LPT1-LPT9 > AUX > > Do you know of any others? > > Larry > > -Original Message- > From: Bill Barker [mailto:[EMAIL PROTECTED]] > Sent: Tue 1/8/2002 7:43 PM > To: Tomcat Developers List > Cc: > Subject: Re: KPMG-2002003: Bea Weblogic DOS-device Denial of Service > > > > 1.3.0_01 returns true for isFile on my Win-NT box. > > I've attached the program I've been running (so as to avoid having to > load > all of Tomcat. > - Original Message - > From: "Larry Isaacs" <[EMAIL PROTECTED]> > To: "Tomcat Developers List" <[EMAIL PROTECTED]> > Sent: Tuesday, January 08, 2002 4:01 PM > Subject: RE: KPMG-2002003: Bea Weblogic DOS-device Denial of Service > > > I find that isFile() returns false, at least for JDK 1.3.1 and > JDK1.2.2. > I tried JDK1.1.8, but Tomcat 3.3.x wouldn't come up. I get: > > java.lang.ClassNotFoundException: > org.apache.tomcat.startup.EmbededTomcat > at org.apache.tomcat.util.compat.SimpleClassLoader.loadClass > > My preference would be to build a solution on isFile() if it can be > worked > out. > I still need to investigate where the test might best be applied. > > Larry > > -Original Message- > From: Bill Barker [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] > Sent: Tue 1/8/2002 3:39 PM > To: Tomcat Developers List > Cc: > Subject: Re: KPMG-2002003: Bea Weblogic DOS-device Denial of Service > > This may be too kludgy, but my quick test shows that "aux.ver" > returns -1164447360 for lastModified. > > Less kludgy would be to simply add a complete list of DOS devices to > the > "keywords" that are mangled. > > - Original Message - > From: "Larry Isaacs" <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > To: "'Tomcat Developers List'" <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > > Sent: Tuesday, January 08, 2002 12:06 PM > Subject: RE: KPMG-2002003: Bea Weblogic DOS-device Denial of Service > > This also causes Tomcat 3.3 to hang a thread when it > tries to read aux.ver. Tomcat 3.2.4 doesn't appear > to have a problem and reports a "not found" error. > A quick test of Tomcat 4.0.1 returned a blank page > without hanging. > I'll investigate and prepare, if possible, a quick > patch to Tomat 3.3 and make a proposal for a > Tomcat 3.3.1 beta and release. > Thanks for relaying this. > Cheers, > Larry > > -Original Message- > > From: Jon Scott Stevens [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] > > Sent: Tuesday, January 08, 2002 2:36 PM > > To: tomcat-dev > > Subject: FW: KPMG-2002003: Bea Weblogic DOS-device Denial of > Service > > > > > > I'm curious how Tomcat deals with this issue. > > > > Oh yea. Yet another reason why JSP sucks. :-) > > > > -jon > > > > -- Forwarded Message > > From: Peter Gründl <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > > > Date: Tue, 8 Jan 20
RE: KPMG-2002003: Bea Weblogic DOS-device Denial of Service
There is one, but it would be better if we didn't have to use native code. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/filesio_697p.asp Platform SDK: File Storage QueryDosDevice The QueryDosDevice function retrieves information about MS-DOS device names. The function can obtain the current mapping for a particular MS-DOS device name. The function can also obtain a list of all existing MS-DOS device names. MS-DOS device names are stored as symbolic links in the object name space. The code that converts an MS-DOS path into a corresponding path uses these symbolic links to map MS-DOS devices and drive letters. The QueryDosDevice function enables an application to query the names of the symbolic links used to implement the MS-DOS device namespace as well as the value of each specific symbolic link. DWORD QueryDosDevice( LPCTSTR lpDeviceName, // MS-DOS device name string LPTSTR lpTargetPath, // query results buffer DWORD ucchMax // maximum size of buffer ); --- David Bullock <[EMAIL PROTECTED]> wrote: > What about an API to list DosDevices? Sorry if you already looked. > > cheers, > David. > > On Tue, 8 Jan 2002, Jim Seach wrote: > > > And unfortunately, I also found this: > > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/filesio_697p.asp > > > > Platform SDK: File Storage > > > > DefineDosDevice > > The DefineDosDevice function defines, redefines, or deletes MS-DOS > > device names. > > > > BOOL DefineDosDevice( > > DWORD dwFlags, // options > > LPCTSTR lpDeviceName, // device name > > LPCTSTR lpTargetPath // path string > > ); > > -- > > David Bullock - [EMAIL PROTECTED] +61 4 0290 1228 > http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ > (President, SA) > http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer > for Java 2 > > "The key ingredients of success are a crystal-clear goal, a realistic > attack plan to achieve that goal, and consistent, daily action to > reach that goal." > Steve Maguire, "Debugging the Development Process". > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: [PATCH] change JDBCRealm to add flexibility in table layout
Ignacio, Forgive me if I don't understand, but it appears you are saying that JDBCRealm's use of a sub-optimal table design is *flexible* because there are ways in some databases to modify a correct schema (by adding a view) to make it work with JDBCRealm? It seems to me in this case that it is the database that is being flexible not JDBCRealm! In other words, users of databases such as MySQL or small pure Java databases like HSQL or McCoi are out of luck because we refuse a *backward compatible* patch that would allow them to work with their existing, correct db design? It seems to me that true flexiblilty in our code would be to allow JDBCRealm to work with multiple database designs without requiring the addition of views or modification of table designs. Jim Seach --- "Ignacio J. Ortega" <[EMAIL PROTECTED]> wrote: > > De: John Gregg [mailto:[EMAIL PROTECTED]] > > Enviado el: miércoles 6 de marzo de 2002 15:26 > > > provided, but I consider it an improvement nonetheless because I > value > > flexible designs. I would expect the MySQL users to > > a flexible design is what you get in JDBCREalm, dont misinterpret me, > the db design you've been proposing is the "Right One" :) I'm not > discussing that, but i think flexible design is the one that lets > you > achieve your goals without modiying the code, i'm achiving your goals > without modifying the code, ergo the Actual JDBCRealm is flexible > enough > to suit your needs, hence proved the first hypotesis.., JDBCRealm is > flexible enough already :) > > Do you want, finally, to solve some flaws in MySql, as the lack of > views? well not a problem, but is something that is very bad for my > taste ( and my taste was modelled after some of our local gurus) > > Anyone has other comments? > > Saludos , > Ignacio J. Ortega > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: [PATCH] change JDBCRealm to add flexibility in table layout
Ignacio, I apologize for not reading more closely. You didn't -1 it, just expressed your opinion. I agree your proposed changes would be much more flexible. Another option that might be nice would be the ability to specify a user supplied class to compute a password hash so only the hash needs to be stored in the database rather than the actual password. I usually use custom authentication rather than using the container provided capabilities, but there may be times when this might be useful, so having well thought out and flexible components is always important! Thanks, Jim Seach --- "Ignacio J. Ortega" <[EMAIL PROTECTED]> wrote: > > De: Jim Seach [mailto:[EMAIL PROTECTED]] > > Enviado el: jueves 7 de marzo de 2002 14:16 > > > > > Ignacio, > > > > Forgive me if I don't understand, but it appears you are saying > that > > JDBCRealm's use of a sub-optimal table design is *flexible* because > > there are ways in some databases to modify a correct schema (by > adding > > a view) to make it work with JDBCRealm? It seems to me in this > case > > that it is the database that is being flexible not JDBCRealm! > > > > This is right.. > > But just now JDBCRealm only need the information it gets from the db, > users, passwords and roles, why mess a simple but efective design > with > another that doenst adds a high degree of flexibility ( although it > patterns data in a way that seems correct to everybody including me > ), i'm only saying that the explanation supporting this patch > were > not correct..John stated in his first messages, that views doesnt > solve > his problem.. this is not right, views do solve his problem.. > > > In other words, users of databases such as MySQL or small pure Java > > databases like HSQL or McCoi are out of luck because we refuse a > > *backward compatible* patch that would allow them to work with > their > > existing, correct db design? > > > > We have not refused nothing, nobody has committed it, so until now, > we > are only speaking, i'm not the only how can commit the patch, btw it > seems working for me, so i will not -1 it, simply i dont like it.. > but > this is just my opinion.. > > Instead i would be glad to champion and commit a patch that do solve > a > more broad version of the problem, not just adding another layer of > indirection to the relation between roles and users.. this can be > done > in the db if needed, it's not a flaw or inflexibility in the > JDBCRealm, > is a flaw in a db.. > > What i would like to see in a patch to JDBCRealm? > > Add a UserSql attribute to JDBCRealm to be used instead of composing > internally a select, and the same for the roles, this could solve a > broader range of problems, than this patch solves by itself.. and > will > make JDBCRealm compatible with any other past or future db.. and will > scartch my own itches.. probably if nobody takes over that i will > last > doing it this way, if nobody complaints, but any help is welcomed as > ever.. > > > Saludos , > Ignacio J. Ortega > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: [PATCH] change JDBCRealm to add flexibility in table layout
--- "Ignacio J. Ortega" <[EMAIL PROTECTED]> wrote: > > De: Jim Seach [mailto:[EMAIL PROTECTED]] > > Enviado el: jueves 7 de marzo de 2002 16:38 > > > > > Ignacio, > > > > I apologize for not reading more closely. You didn't -1 it, just > > And i apologize everybody for writing english so bad :), Your English is better than my anything else! > > > expressed your opinion. I agree your proposed changes would be > much > > more flexible. Another option that might be nice would be the > ability > > to specify a user supplied class to compute a password hash > > so only the > > hash needs to be stored in the database rather than the actual > > password. > > > > Do you know that Realms in general already have Digest capability > inside? > > Or Are you asking for a new feature? A new feature, but a suggestion rather than a request. Even if the client realm doesn't support Digest authentication, we can use Basic or Form to get the user ID and password in the clear, then apply the hash function to compare with the hash stored in the database. Using Digest authentication is better, but it may not be an option for all browsers. Maybe some of the Digest code could be reused. Actually, I prefer to authenticate against the database by logging in using the user ID and password supplied, and let the database provide the authentication and access control, but for most databases this doesn't play well with connection pooling. > > Saludos , > Ignacio J. Ortega > Jim Seach > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
RE: [PATCH] change JDBCRealm to add flexibility in table layout
--- "Ignacio J. Ortega" <[EMAIL PROTECTED]> wrote: > > De: Jim Seach [mailto:[EMAIL PROTECTED]] > > Enviado el: jueves 7 de marzo de 2002 18:08 > > > > > A new feature, but a suggestion rather than a request. Even if the > > client realm doesn't support Digest authentication, we can > > use Basic or > > Form to get the user ID and password in the clear, then apply the > hash > > > I was not talking about Digest auth in HTTP sense, sorry for not be > clear, i was talking about tc Realms, they already have the ability > of > use hashed passswords, with selectable hasshing algorithm, right out > the > box.. > And it is well documented in the Realm-How-To! I swear, I read it before, but for some reason it didn't stick. Sorry! > > Saludos , > Ignacio J. Ortega > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
