Mandragora 0.3.2 released : Ejb support
Mandragora (http://mandragora.sourceforge.net/) is an opensource framework that provides a pre-built infrastructure for every kind of java application. Mandragora is a generic business layer highly configurable and easily extensible, suitable for distributed applications as well, that come with more than 100 generic business methods , and that allows you to reuse the methods you write, keeping the infrastructure that implements the J2ee patterns. It has been fully tested for JBOSS and TOMCAT, and it can be considered a component of the middleware. If you use a MVC pattern in the application that you have to design and implement, Mandragora provides you the infrastructure for the Model. Typically, with MVC, the controller has to update or query the model, and the view can query the model as well. The model should be decoupled from controller or view by a business delegate layer. So all access to the model should pass trough the BD. Mandragora provides more than one hundred of business methods, that your controller for example, has just to call, without worrying about their implementation (IoC). So How such methods call service facade, application services ,and DAO methods, is not about your care. Just do bd.findByPrimarykey() or bd. storePathsCascade(...) and much more, to execute very complex operations and queries such storing or modifying very complex objects in the DB. Then you can extend the service facade, application services and Dao implementation very easily, to better fit your requirements, as Mandragora porvides a very easy to use IoC mechanism, to allow you to choose which implementation of BD, ApplicationService, Service FAcade or DAO interface to use, even at runtime. You should spend some minutes downloading and trying it, to see, how much time you can save, having yet ready to use the most common operations (many crud methods and much more complex business methods), so in your work you have just to focus on the particular Business Intelligence of your concrete project, as all such bothering operations that you have to repeat project after project, are already done, once for ever, and if you improve them, such work is done for all your projects. Moreover all of that is implemented using a well done infrastructure using the J2ee patterns, so extending Mandragora (http://mandragora.sourceforge.net/) for the business method that you have to implement because you don't find in the provided ones, you are guaranteed to implement a well done architecture. If you wish to write new BD methods, you can do in terms of the already existing Servcice Facade methods, or mixing with new SF methods written by your own, that in turn ca be implemented in terms of existing Application Service or DAO methods, or in terms of new ones that you write. All this is very easy to use. Download and spend 30 minutes. You will save week of work. Best regards Alessandro Colantoni http://mandragora.sourceforge.net/
Re: How to disable cookies for session management in Tomcat
Hi You have to put in your context cookies=false For more have a look at http://tomcat.apache.org/tomcat-5.5-doc/config/context.html hope this help On 8/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi there. Is there any way to tell Tomcat to never use cookies for session management? Regards, Luís Amorim - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic roles web.xml
Hi Mark Just to tell that I finished my job and all work well. Thanks a lot to guide me Now I have a taglib that does for example perm:present list=1,4,21,33 all=false do your job /perm if the user in session is related with at least one role that is related with at least one of the permissions in list the job is done. On 3/17/06, Alessandro Colantoni [EMAIL PROTECTED] wrote: On 3/17/06, Mark Lowe [EMAIL PROTECTED] wrote: Hang on!!! You've an admin form where you have dynamic roles, right? And you've no means of knowing what these will be.. And what they are denying access to.. Doing this with your proposed taglib wont help solve this.. Your tag or jsp bean is going to have to ask the database which roles have what access to a given page. Right! that was what I was going to do , but you scared me! I don't understand why I need a reference to the user action/jsp in the database Roles are dynamic, relationships between roles and permissions are dynamic too, but permissions on jsp and single objects of jsp are static. In my jsp, I fix statically which permissions are . My taglib just has to verify if the user has one of the role with specified permissions(perm1 , perm2) querying the database to decide if to show the page, if to show a denying message, or show fields editable or not. Alessandro On 3/17/06, Mark Lowe [EMAIL PROTECTED] wrote: On 3/17/06, Alessandro Colantoni [EMAIL PROTECTED] wrote: Hi! again!! Of course I'm Italian, but at moment I'm living in Spain for work, so just the same continent .! At the end I will choose the jsp solution with taglib (I'm gonna write my permission taglib now!) 'cause reference pages in database can be too much work and in some case I have permissions at field level. I think I yet found the solution to make such a taglib generic to re use in all future applications I'll do something like that permissions:present list=perm1,perm2,perm3 !-- write your jsp piece -- /permissions:present permissions:notPresent list=perm1,perm2,perm3 !-- write your jsp piece -- /permissions:notPresent Hang on!!! You've an admin form where you have dynamic roles, right? And you've no means of knowing what these will be.. And what they are denying access to.. Doing this with your proposed taglib wont help solve this.. Your tag or jsp bean is going to have to ask the database which roles have what access to a given page.. Your stuck needing a reference to the user action/jsp in the database. You could have a properties file mapping jsp's to a key and keep that in the db. But you're going to need this to have truely dynamic roles to view access control.. Mark That seems more easy to maintain cause in my application I have just to maintain the relationship between roles and permissions Thanks a lot for your help! I hope you enjoy in my country Alessandro On 3/17/06, Mark Lowe [EMAIL PROTECTED] wrote: On 3/17/06, Mark Lowe [EMAIL PROTECTED] wrote: On 3/17/06, Alessandro Colantoni [EMAIL PROTECTED] wrote: Hi! and good morning (but probably we 're on different continents) Assiming you're in italy, we're in the same country.. I don't undertand the last pos where you say. I had the impression he already had.. I don't get how posting this helps, i must have misunderstood something.. Can you explain please? Anyway thanks for accurate explication. I'll go studing how to write the filter class I think that as you say the right way is to have at least one role mapped on web.xml, forbid to delete it from database and ensure all user have this rol. So I can still use the yet configured container based authentication. Than check for permission in each page in the filter class, or, i was thinking check it directly in the jsp. I was thinking write a taglib to do so. (that should check if the user has at least a role that has at least one of the permissions for this page) Wich is the difference between jsp solution and filter class solution? Is filter class more secure? I did forget to outline the advantages of defining this stuff in jsp.. You don't need to have a reference to the page in your database.. Which i guess is a big advantage.. Again its your choice.. Mark Its more secure in that you don't depend on jsp folk on getting it right, given that your having to do some view controller stuff in your db it would seem a shame not to control this in a filter... You can also disactivate the filter during development and let jsp folk write decent markup, without giving them the secondary problem of secuirty logic. You could just write a simple bean
Re: Custom realm extending JDBCRealm
HI!!
Just solved.
I was using tomcat 5.5.0.
I was looking at sources of 5.5.16.
I suppose that the authenticate method of 5.5.0 doesn't use getPassord
method.
I tried it in 5.5.16 and everything works fine
Thanks for attention
Alessandro
On 3/24/06, Alessandro Colantoni [EMAIL PROTECTED] wrote:
Hi all!
For some reasons I had to extend JDBCRealm to overwrite the method
getPassword.
This is myRealm:
public class ManoloJDBCRealm extends JDBCRealm{
private static Log log = LogFactory.getLog(ManoloJDBCRealm.class);
protected String getPassword(String username) {
System.out.println(username= +username);
String password=super.getPassword(username);
log.info(password=+password);
String hexpassword=HexUtils.convert(password.getBytes());
log.info(hexpassword=+hexpassword);
return hexpassword;
}
}
I wrote the file mbeans-descriptors.xml
?xml version=1.0?
mbeans-descriptors
mbean name=ManoloJDBCRealm description=Implementation of Realm
that works with any JDBC supported database domain=Catalina group=Realm
type= com.steria.tc.realm.ManoloJDBCRealm
attribute name=className description=Fully qualified class name
of the managed object type=java.lang.String writeable=false /
attribute name=connectionName description=The connection
username to use when trying to connect to the database type=
java.lang.String /
attribute name=connectionPassword description=The connection URL
to use when trying to connect to the database type= java.lang.String /
attribute name=connectionURL description=The connection URL to
use when trying to connect to the database type=java.lang.String /
attribute name=digest description=Digest algorithm used in
storing passwords in a non-plaintext format type= java.lang.String /
attribute name=driverName description=The JDBC driver to use
type=java.lang.String /
attribute name=roleNameCol description=The column in the user
role table that names a role type= java.lang.String /
attribute name=userCredCol description=The column in the user
table that holds the user's credentials type=java.lang.String /
attribute name=userNameCol description=The column in the user
table that holds the user's username type= java.lang.String /
attribute name=userRoleTable description=The table that holds
the relation between user's and roles type=java.lang.String /
attribute name=userTable description=The table that holds user
data type= java.lang.String /
operation name=start description=Start impact=ACTION
returnType=void /
operation name=stop description=Stop impact=ACTION
returnType=void /
operation name=init description=Init impact=ACTION
returnType=void /
operation name=destroy description=Destroy impact=ACTION
returnType=void /
/mbean
/mbeans-descriptors
I just copied it form the JDBCRealm and change the type.
This file is in the same package of ManoloJDBCRealm.
In server.xml I put
Listener className=org.apache.catalina.mbeans.ServerLifecycleListener
debug=0
descriptors=/com/steria/tc/realm/mbeans-descriptors.xml/
I've done a jar with in com/steria/tc/realm/mbeans-descriptors.xml,
ManoloJDBCRealm.class
and I put it in server/lib
In my context.xml I put
Realm className = com.steria.tc.realm.ManoloJDBCRealm../
I start tomcat, I get no error, but when i authenticate I don't get one of
the message of my custom getPassword(String username). The behavior is as if
tomcat utilize the JDBCREalm method
Thanks in advance Alessandro
Re: return (HexUtils.convert(md.digest())) in RealmBase
I solved the last problem passing to tomcat 5.5.16 .
At the end everything work as i desired (well i didn't do many tests so
that's what I hope).
Thanks your help and your patience
Alessandro
On 3/24/06, Alessandro Colantoni [EMAIL PROTECTED] wrote:
Hi!
One day after i understood what you explained me.
HexUtils.convert just do an hex representation in a string format of the
binary number represented by the array of byte.
I taught that a solution to my problem could be implement a custom realm,
that extends JDBCrealm and overwrite the method getPassword in such a way
protected String getPassword(String username) {
System.out.println(username= +username);
String password=super.getPassword(username);
log.info(password=+password);
String hexpassword=HexUtils.convert(password.getBytes());
log.info(hexpassword=+hexpassword);
return hexpassword;
}
In theory should work , but I don't know why tomcat still uses the
getPassword of the JDBCrealm , cause I don't see messages printed.
But this is an other problem, and that's better I open another thread.
I hope I'm following the rigtht way
On 3/23/06, Alessandro Colantoni [EMAIL PROTECTED] wrote:
Hi !
I'm lost. Sorry.
I don't understand when you say
I can guarantee that
MessageDigest.digest(), which returns an array of bytes, will NOT
return an
array of bytes every time that can be transmitted on a URL i.e. is a
printable
string.
I will try to explain better what I have done
I have an algorithm called manolo (from the name of the manager of the
other application that passed it to me).
I wrote a class
public class ManoloMessageDigestSpi extends MessageDigestSpi implements
Cloneable
I have in this class the field
private byte[] digest = null;
I implemented the method engineDigest:
protected byte[] engineDigest(){
byte[] completedDigest=this.digest;
engineReset();
return completedDigest;
}
in the engineUpdate(byte input) I just set the field digest with the
encrypted value of input using the manolo algorithm.
I wrote a Provider called ManoloProvider
public final class ManoloProvider extends Provider{
public ManoloProvider() {
super(manolo, 1.0, algoritmo pasado por Manolo el
21-03-2006);
put (MessageDigest.manolo,
com.steria.tc.security.ManoloMessageDigestSpi );
}
}
Then in a servlet that load on startup I do something like that
Security.addProvider(new ManoloProvider)
In the context.xml of my application I put
Realm className = org.apache.catalina.realm.JDBCRealm
digest=manolo
.
/
When The other application(developed in power builder) store a password
use the manolo algorithm to encrypt it. So what it stores is the same
value of
MessageDigest.update(cleartext);
MessageDigest.digest().toString().
So let's call:
cleartext : password in cleartext
digested : password encrypted
converted: digested converted with HexUtils.convert
At the end, when Tomcat authenticates it will compare converted with
digested and always fail.
Everything work fine if was my application to store password, storing
RealmBase.Digest(cleartext,manolo)
Thanks for attention
Alessandro
On 3/22/06, Jay Burgess [EMAIL PROTECTED] wrote:
Then maybe I'm misunderstanding something. But I can guarantee that
MessageDigest.digest(), which returns an array of bytes, will NOT
return an
array of bytes every time that can be transmitted on a URL i.e. is a
printable
string. That's why it has to be encoded in some form, and two hex
chars/bytes
is the way this gets encoded.
However, if you really do want to undo the encoding, simply reverse
the logic of
the encode() method in the MD5Encoder.java file.
Alternatively, if you are just trying to authenticate something in
your code, it
may work to just run through the digest and encode steps yourself,
then compare
your end result with what the user sent. If they're the same, then
they're
authenticated, without you needing to undo anything.
Jay
-Original Message-
From: Alessandro Colantoni [mailto: [EMAIL PROTECTED]
Sent: Wednesday, March 22, 2006 12:37 PM
To: Tomcat Users List
Subject: Re: return (HexUtils.convert(md.digest())) in RealmBase
Thanks for answer.
I'm sure that the byte representation is printable, because that's a
very
easy algorithm, and it is working since some year storing correct
encrypted
password with the other application.
What i should need is an inverse operation of the HexUtils.convert.
Is there such an algorithm?
I 'll explain better.
Lets call this inverse operation convert_inv.
It should be so that
HexUtils.convert
(convert_inv(myAlgorithm(myClearCredential
Re: return (HexUtils.convert(md.digest())) in RealmBase
Hi !
I'm lost. Sorry.
I don't understand when you say
I can guarantee that
MessageDigest.digest(), which returns an array of bytes, will NOT return an
array of bytes every time that can be transmitted on a URL i.e. is a
printable
string.
I will try to explain better what I have done
I have an algorithm called manolo (from the name of the manager of the other
application that passed it to me).
I wrote a class
public class ManoloMessageDigestSpi extends MessageDigestSpi implements
Cloneable
I have in this class the field
private byte[] digest = null;
I implemented the method engineDigest:
protected byte[] engineDigest(){
byte[] completedDigest=this.digest;
engineReset();
return completedDigest;
}
in the engineUpdate(byte input) I just set the field digest with the
encrypted value of input using the manolo algorithm.
I wrote a Provider called ManoloProvider
public final class ManoloProvider extends Provider{
public ManoloProvider() {
super(manolo, 1.0, algoritmo pasado por Manolo el 21-03-2006);
put (MessageDigest.manolo,
com.steria.tc.security.ManoloMessageDigestSpi);
}
}
Then in a servlet that load on startup I do something like that
Security.addProvider(new ManoloProvider)
In the context.xml of my application I put
Realm className = org.apache.catalina.realm.JDBCRealm
digest=manolo
.
/
When The other application(developed in power builder) store a password
use the manolo algorithm to encrypt it. So what it stores is the same value
of
MessageDigest.update(cleartext);
MessageDigest.digest().toString().
So let's call:
cleartext : password in cleartext
digested : password encrypted
converted: digested converted with HexUtils.convert
At the end, when Tomcat authenticates it will compare converted with
digested and always fail.
Everything work fine if was my application to store password, storing
RealmBase.Digest(cleartext,manolo)
Thanks for attention
Alessandro
On 3/22/06, Jay Burgess [EMAIL PROTECTED] wrote:
Then maybe I'm misunderstanding something. But I can guarantee that
MessageDigest.digest(), which returns an array of bytes, will NOT return
an
array of bytes every time that can be transmitted on a URL i.e. is a
printable
string. That's why it has to be encoded in some form, and two hex
chars/bytes
is the way this gets encoded.
However, if you really do want to undo the encoding, simply reverse the
logic of
the encode() method in the MD5Encoder.java file.
Alternatively, if you are just trying to authenticate something in your
code, it
may work to just run through the digest and encode steps yourself, then
compare
your end result with what the user sent. If they're the same, then
they're
authenticated, without you needing to undo anything.
Jay
-Original Message-
From: Alessandro Colantoni [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 22, 2006 12:37 PM
To: Tomcat Users List
Subject: Re: return (HexUtils.convert(md.digest())) in RealmBase
Thanks for answer.
I'm sure that the byte representation is printable, because that's a very
easy algorithm, and it is working since some year storing correct
encrypted
password with the other application.
What i should need is an inverse operation of the HexUtils.convert.
Is there such an algorithm?
I 'll explain better.
Lets call this inverse operation convert_inv.
It should be so that
HexUtils.convert
(convert_inv(myAlgorithm(myClearCredential)))=myAlgorithm(myClearCredential).
So including convert_inv in myAlgorithm (while the other application
follow
with the original one) I solve my problem.
Is it possible?
Thanks for help
Alessandro
On 3/22/06, Jay Burgess [EMAIL PROTECTED] wrote:
I think this is the right answer:
digest() returns a sequence of bytes. Depending on the values of the
individual
bytes, if you were to try and convert it to String, you can end up with
non-printable characters, etc.
I'm assuming that HexUtils.convert() turns each 4 bits of each byte into
a
hex
character, so that you end up with a proper String representation of the
digest
that can be sent as part of a URL.
Jay
| Jay Burgess [Vertical Technology Group]
| http://www.vtgroup.com/
-Original Message-
From: Alessandro Colantoni [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 22, 2006 12:12 PM
To: Tomcat Users List
Subject: return (HexUtils.convert(md.digest())) in RealmBase
Hi All!
I saw that both method Digest(..) and digest(..) in RealmBase return (
HexUtils.convert(md.digest())) and not just
md.digest().toString.
My problem is that user table is maintained by another application
developed
in an other technology.
My application uses this table just to authenticate.
The password of user table is encrypted with an algorithm I've been
done.
I wrote a MessageDigestSpi for that algorithm, I wrote my provider, I
registered
return (HexUtils.convert(md.digest())) in RealmBase
Hi All! I saw that both method Digest(..) and digest(..) in RealmBase return ( HexUtils.convert(md.digest())) and not just md.digest().toString. My problem is that user table is maintained by another application developed in an other technology. My application uses this table just to authenticate. The password of user table is encrypted with an algorithm I've been done. I wrote a MessageDigestSpi for that algorithm, I wrote my provider, I registered it and everything looks work fine. Except that of course if I do: RealmBase.Digest(myCredentials,myAlgorithm); I get a result different from doing MessageDigest md = MessageDigest.getInstance(myAlgorithm); md.update(myCredentials.getBytes()); md.digest().toString; but the same result of MessageDigest md = MessageDigest.getInstance(myAlgorithm); md.update(myCredentials.getBytes()); HexUtils.convert(md.digest()) So the problem is that the other application stores without using the HexUtils.convert method but when tomcat authenticates it uses it. One solution could be write a Realm class that extends the JDBCRealm (the one I'm using) and overwrite these methods. But I'm afraid that in different versions of Tomcat (i don't want link to one) could be different signature of these methods. There's another solution? At least avoiding overwriting these very important methods? And just for curiosity, why HexUtils.convert has been utilized? Thanks in advance for help and have a nice springtime Alessandro
Re: Dynamic roles web.xml
Hi! and good morning (but probably we 're on different continents) I don't undertand the last pos where you say. I had the impression he already had.. I don't get how posting this helps, i must have misunderstood something.. Can you explain please? Anyway thanks for accurate explication. I'll go studing how to write the filter class I think that as you say the right way is to have at least one role mapped on web.xml, forbid to delete it from database and ensure all user have this rol. So I can still use the yet configured container based authentication. Than check for permission in each page in the filter class, or, i was thinking check it directly in the jsp. I was thinking write a taglib to do so. (that should check if the user has at least a role that has at least one of the permissions for this page) Wich is the difference between jsp solution and filter class solution? Is filter class more secure? Thanks a lot Ciao! PS . good italian. What does it mean schete? On 3/17/06, Mark Lowe [EMAIL PROTECTED] wrote: On 3/17/06, Mark Space [EMAIL PROTECTED] wrote: Alessandro Colantoni wrote: Thanks for rapid answer! What do you mean with filter the roles of second level. How can I do that? if they are not in the auth-constraint and in the role name list they can't access. have O to write a filter class? in this class retrieve the role of the user and if is one of the second level skip the container authentication? I'm in the right way or I misunderstand all? Or you could try this: http://tomcat.apache.org/tomcat-4.1-doc/realm-howto.html I had the impression he already had.. I don't get how posting this helps, i must have misunderstood something.. Can you explain please? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic roles web.xml
Hi! again!! Of course I'm Italian, but at moment I'm living in Spain for work, so just the same continent .! At the end I will choose the jsp solution with taglib (I'm gonna write my permission taglib now!) 'cause reference pages in database can be too much work and in some case I have permissions at field level. I think I yet found the solution to make such a taglib generic to re use in all future applications I'll do something like that permissions:present list=perm1,perm2,perm3 !-- write your jsp piece -- /permissions:present permissions:notPresent list=perm1,perm2,perm3 !-- write your jsp piece -- /permissions:notPresent That seems more easy to maintain cause in my application I have just to maintain the relationship between roles and permissions Thanks a lot for your help! I hope you enjoy in my country Alessandro On 3/17/06, Mark Lowe [EMAIL PROTECTED] wrote: On 3/17/06, Mark Lowe [EMAIL PROTECTED] wrote: On 3/17/06, Alessandro Colantoni [EMAIL PROTECTED] wrote: Hi! and good morning (but probably we 're on different continents) Assiming you're in italy, we're in the same country.. I don't undertand the last pos where you say. I had the impression he already had.. I don't get how posting this helps, i must have misunderstood something.. Can you explain please? Anyway thanks for accurate explication. I'll go studing how to write the filter class I think that as you say the right way is to have at least one role mapped on web.xml, forbid to delete it from database and ensure all user have this rol. So I can still use the yet configured container based authentication. Than check for permission in each page in the filter class, or, i was thinking check it directly in the jsp. I was thinking write a taglib to do so. (that should check if the user has at least a role that has at least one of the permissions for this page) Wich is the difference between jsp solution and filter class solution? Is filter class more secure? I did forget to outline the advantages of defining this stuff in jsp.. You don't need to have a reference to the page in your database.. Which i guess is a big advantage.. Again its your choice.. Mark Its more secure in that you don't depend on jsp folk on getting it right, given that your having to do some view controller stuff in your db it would seem a shame not to control this in a filter... You can also disactivate the filter during development and let jsp folk write decent markup, without giving them the secondary problem of secuirty logic. You could just write a simple bean (as an other option) and use the trusty useBean tag, but you'll be depending on jsp folk on getting this right.. A filter is just tidier.. Thanks a lot Ciao! PS . good italian. What does it mean schete? My bad spelling for scelte mark On 3/17/06, Mark Lowe [EMAIL PROTECTED] wrote: On 3/17/06, Mark Space [EMAIL PROTECTED] wrote: Alessandro Colantoni wrote: Thanks for rapid answer! What do you mean with filter the roles of second level. How can I do that? if they are not in the auth-constraint and in the role name list they can't access. have O to write a filter class? in this class retrieve the role of the user and if is one of the second level skip the container authentication? I'm in the right way or I misunderstand all? Or you could try this: http://tomcat.apache.org/tomcat-4.1-doc/realm-howto.html I had the impression he already had.. I don't get how posting this helps, i must have misunderstood something.. Can you explain please? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dynamic roles web.xml
Hi all! In my application I need to define roles dynamically. I need to create and delete roles and associate them to a permissions table. I want the user authenticate with a form. The problem is that in web.xml I have to define statically the role names. This is the involved piece of my web.xml security-constraint web-resource-collection web-resource-nameMain/web-resource-name url-pattern/do/main/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection auth-constraint role-nameC/role-name role-nameE/role-name role-nameEQ/role-name role-nameF/role-name role-nameL/role-name role-nameM/role-name role-nameP/role-name role-namePS/role-name role-nameTO/role-name role-nameTS/role-name role-nameV/role-name role-name0/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method realm-nameJDBCRealm/realm-name form-login-config form-login-page/login.jsp/form-login-page form-error-page/login-err.jsp/form-error-page /form-login-config /login-config security-role role-nameC/role-name role-nameE/role-name role-nameEQ/role-name role-nameF/role-name role-nameL/role-name role-nameM/role-name role-nameP/role-name role-namePS/role-name role-nameTO/role-name role-nameTS/role-name role-nameV/role-name role-name0/role-name /security-role If I create a new role called NEWROLE how can I make it authorized? Is there a way to change dynamically this piece of web.xml? For example some api that add a new entry role-nameNEWROLE /role-name Analogously if I delete a role I want it no more authorized. Has this problem a solution? Thanks for attention Alessandro
Re: Session crash problem. Please help!
Hi Martin. Thanks for interest!. I have tomcat 5.5.7 not running as service (I have it at work and now I'm at home) and I don't have /logs/stderr.log (??). Stdout is my MS-DOS windows and I don't think that's important. I have a preprocessor that just checks if request.getSession(false)==null or isnew() to redirect to the expired-session page. So I don't get anything strange as everything go as session was expired. On linux (tomcat 5.5.12) I have in logs folder the following: catalina.out (I think it is stdout.log) localhost.date.log, manager.date.log, catalina.date.log, admin.date.log, hostmanager.date.log I think you need localhost.date.log. I don't see stderr.log I can produce error on linux just tomorrow at work 'cause I have DB on windows partition. On tomcat on windows I don't know why I don't have stderr.log My Tomcat-home/logs is empty. What have I to set to have it? What should I look for in stderr.log?? Thanks a lot! Alessandro On 12/2/05, Martin Gainty [EMAIL PROTECTED] wrote: Allesandro can you attach the stderr_20051202.log stdout_20051202.log Ciao Martin- - Original Message - From: Alessandro Colantoni [EMAIL PROTECTED] To: users@tomcat.apache.org Sent: Friday, December 02, 2005 5:47 AM Subject: Session crash problem. Please help! Hi All I configured on conf/web.xml session timeout on 180 minutes and on my web.xml too. I have the following context.xml Context path=/trayectorias docBase=trayectorias relodable=false crossContext=false privileged=true debug=99 Manager className=org.apache.catalina.session.StandardManager debug=0 checkInterval=60 entropy=asdfghjklASDFGHJKLwefgbnmASDFGHJKLwedfgbhnxcvfghjukifgbhn maxActiveSessions=-1 pathname = maxInactiveInterval=-1 /Manager Realm className=org.apache.catalina.realm.MemoryRealm debug=99 pathname=webapps/trayectorias/WEB-INF/classes/resources/trayectorias-users.xml/ /Context session crash very often. it crashes while working too, without leaving any inactivity as well I tried with tomcat 4.1, 5.5.5, 5.5.7,5.5.12 on windows xp and on linux I tried with session.PersistentManager too. I'm working with struts and problem deals when I deal with a big object in session I though it was an heap size problem. I allocated 500m to the heap and I noticed it crashed when tomcat had 400M free. Session get destroyed without any apparent reason so user is just trowed out I've been dealing with this for 2 months, and it looks as just me I have this problem. So probably I'm doing some stupid thing, but I can't get it Please help Thanks for attention Alessandro! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Session crash problem. Please help!
Hi All I configured on conf/web.xml session timeout on 180 minutes and on my web.xml too. I have the following context.xml Context path=/trayectorias docBase=trayectorias relodable=false crossContext=false privileged=true debug=99 Manager className=org.apache.catalina.session.StandardManager debug=0 checkInterval=60 entropy=asdfghjklASDFGHJKLwefgbnmASDFGHJKLwedfgbhnxcvfghjukifgbhn maxActiveSessions=-1 pathname = maxInactiveInterval=-1 /Manager Realm className=org.apache.catalina.realm.MemoryRealm debug=99 pathname=webapps/trayectorias/WEB-INF/classes/resources/trayectorias-users.xml/ /Context session crash very often. it crashes while working too, without leaving any inactivity as well I tried with tomcat 4.1, 5.5.5, 5.5.7,5.5.12 on windows xp and on linux I tried with session.PersistentManager too. I'm working with struts and problem deals when I deal with a big object in session I though it was an heap size problem. I allocated 500m to the heap and I noticed it crashed when tomcat had 400M free. Session get destroyed without any apparent reason so user is just trowed out I've been dealing with this for 2 months, and it looks as just me I have this problem. So probably I'm doing some stupid thing, but I can't get it Please help Thanks for attention Alessandro! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
session expires dealing with big objects
Hi all. Some times my session expires wrongly when I deal with a bean very big. My bean is a Struts form bean. I didn't touch conf/server.xml and conf/web.xml of tomcat distribution In my web.xml I put session-config session-timeout180/session-timeout /session-config I've done such a file context.xml: Context path=/trayectorias docBase=trayectorias relodable=false crossContext=true privileged=true debug=99 !-- PersistentManager: Uncomment the section below to test Persistent Sessions. saveOnRestart: If true, all active sessions will be saved to the Store when Catalina is shutdown, regardless of other settings. All Sessions found in the Store will be loaded on startup. Sessions past their expiration are ignored in both cases. maxActiveSessions: If 0 or greater, having too many active sessions will result in some being swapped out. minIdleSwap limits this. -1 or 0 means unlimited sessions are allowed. If it is not possible to swap sessions new sessions will be rejected. This avoids thrashing when the site is highly active. minIdleSwap: Sessions must be idle for at least this long (in seconds) before they will be swapped out due to activity. 0 means sessions will almost always be swapped out after use - this will be noticeably slow for your users. maxIdleSwap: Sessions will be swapped out if idle for this long (in seconds). If minIdleSwap is higher, then it will override this. This isn't exact: it is checked periodically. -1 means sessions won't be swapped out for this reason, although they may be swapped out for maxActiveSessions. If set to = 0, guarantees that all sessions found in the Store will be loaded on startup. maxIdleBackup: Sessions will be backed up (saved to the Store, but left in active memory) if idle for this long (in seconds), and all sessions found in the Store will be loaded on startup. If set to -1 sessions will not be backed up, 0 means they should be backed up shortly after being used. To clear sessions from the Store, set maxActiveSessions, maxIdleSwap, and minIdleBackup all to -1, saveOnRestart to false, then restart Catalina. -- !-- Manager className=org.apache.catalina.session.PersistentManager debug=0 saveOnRestart=false maxActiveSessions=-1 minIdleSwap=-1 maxIdleSwap=-1 maxIdleBackup=-1 Store className=org.apache.catalina.session.FileStore/ /Manager -- Manager className=org.apache.catalina.session.StandardManager debug=0 checkInterval=60 entropy=asdfghjklASDFGHJKLwefgbnmASDFGHJKLwedfgbhnxcvfghjukifgbhn maxActiveSessions=-1 pathname = maxInactiveInterval=-1 /Manager !-- WatchedResourceWEB-INF/web.xml/WatchedResource -- !-- ResourceLink name=users global=UserDatabase type=org.apache.catalina.UserDatabase/ -- Realm className=org.apache.catalina.realm.MemoryRealm debug=99 pathname=webapps/trayectorias/WEB-INF/classes/resources/trayectorias-users.xml/ /Context Previously I had tried with PersistentManager, and with tomcat 4.1.24, 5.5.0 y 5.5.7 The session expires wrongly only with big object. I tried it in different computers and I notice that smaller is PC mas frequently happens the error. Have I configured something wrong? Is it possible I have to configure some parameter to swap? Is it possible to configure session size in some way? Thanks a lot in advance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
