You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Pere Torrodellas <pt...@fihoca.com> on 2001/04/10 17:16:15 UTC
Security exception with Oracle
The Flux part in the peer application example of TDK 1.1a12 throws an
exception when using Security to insert new elements in Oracle tables.
Both retrieves and updates work OK. Inserts also work when using MySql
instead of Oracle (no, I can't just stick to MySql ;-)
The exception says that NULL has been specified for the ID column
(PERMISSION_ID, ROLE_ID,...). This seems to point to the procedure to
get primary keys, right?
By reproducing the code up to BasePeer.doInsert() in the case of a
Permission, I've seen that the criteria that is passed to
insertOrUpdateRecord() has indeed TURBINE_PERMISSION.PERMISSION_ID=null.
Note that inserts work all right for the example RDF table, with
apparently the same definitions for the primary key.
Can someone suggest the reason for this error? Thanks!
Pere Torrodellas
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Security exception with Oracle
Posted by Pere Torrodellas <pt...@fihoca.com>.
----- Mensaje original -----
>De: John McNally <jm...@collab.net>
>Para: <tu...@jakarta.apache.org>
>Enviado: miércoles 18 de abril de 2001 22:48
>Asunto: Re: Security exception with Oracle
>
> i reapplied my patch after the security branch was merged, so that is
in
> place. I will try to look further, but am quite swamped at the
moment.
> Please submit patches if you get it working.
>
> John McNally
I fixed the problem and report it in another message.
This is to point out that, in addition to RolePeer PermissionPeer and
GroupPeer, the same patch should be also applied to
TurbineUserPeer.buildCiteria() to allow user inserts.
Thanks,
Pere Torrodellas
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Security exception with Oracle
Posted by John McNally <jm...@collab.net>.
Added to cvs.
Thank you.
John McNally
Pere Torrodellas wrote:
>
> > This time I got a new exception, caused ultimately by the fact that
> > TableMap.getPrimaryKeyMethodInfo() returns null when invoked in
> > BasePeer.doInsert() for Security tables. I looked into
> > TurbineMapBuilder, and it seems that the Security TableMaps pkInfo
> > attribute is not being set. Shouldn't it be initialized there?
> >
>
> I managed to fix the error by adding initialization statements for
> TableMap.pkInfo in TurbineMapBuilder. I expect that someone more
> knowledgeable will check this and take advantage of it to build the
> right patch.
>
> Please excuse me if this is not a CVS diff, but:
>
> - I'm testing with the TDK 1.1a12, not the last Turbine source.
> - I'm not used to CVS (yet?).
>
> TurbineMapBuilder.doBuild() {
> ...............
> TableMap tMap = dbMap.getTable(getTableUser());
> tMap.setPrimaryKeyMethod("idbroker_table");
> tMap.setPrimaryKeyMethodInfo(tMap.getName()); /*ADDED*/
> ...............
> tMap = dbMap.getTable(getTableGroup());
> tMap.setPrimaryKeyMethod("idbroker_table");
> tMap.setPrimaryKeyMethodInfo(tMap.getName()); /*ADDED*/
> ................
> tMap = dbMap.getTable(getTableRole());
> tMap.setPrimaryKeyMethod("idbroker_table");
> tMap.setPrimaryKeyMethodInfo(tMap.getName()); /*ADDED*/
> ................
> tMap = dbMap.getTable(getTablePermission());
> tMap.setPrimaryKeyMethod("idbroker_table");
> tMap.setPrimaryKeyMethodInfo(tMap.getName()); /*ADDED*/
> ................
> tMap = dbMap.getTable(getTableJobentry());
> tMap.setPrimaryKeyMethod("idbroker_table");
> tMap.setPrimaryKeyMethodInfo(tMap.getName()); /*ADDED*/
> ................
> }
>
> Pere Torrodellas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Security exception with Oracle
Posted by Daniel Rall <dl...@collab.net>.
"Pere Torrodellas" <pt...@fihoca.com> writes:
> Please excuse me if this is not a CVS diff, but:
>
> - I'm testing with the TDK 1.1a12, not the last Turbine source.
> - I'm not used to CVS (yet?).
http://cvsbook.red-bean.com/
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Security exception with Oracle
Posted by Pere Torrodellas <pt...@fihoca.com>.
> This time I got a new exception, caused ultimately by the fact that
> TableMap.getPrimaryKeyMethodInfo() returns null when invoked in
> BasePeer.doInsert() for Security tables. I looked into
> TurbineMapBuilder, and it seems that the Security TableMaps pkInfo
> attribute is not being set. Shouldn't it be initialized there?
>
I managed to fix the error by adding initialization statements for
TableMap.pkInfo in TurbineMapBuilder. I expect that someone more
knowledgeable will check this and take advantage of it to build the
right patch.
Please excuse me if this is not a CVS diff, but:
- I'm testing with the TDK 1.1a12, not the last Turbine source.
- I'm not used to CVS (yet?).
TurbineMapBuilder.doBuild() {
...............
TableMap tMap = dbMap.getTable(getTableUser());
tMap.setPrimaryKeyMethod("idbroker_table");
tMap.setPrimaryKeyMethodInfo(tMap.getName()); /*ADDED*/
...............
tMap = dbMap.getTable(getTableGroup());
tMap.setPrimaryKeyMethod("idbroker_table");
tMap.setPrimaryKeyMethodInfo(tMap.getName()); /*ADDED*/
................
tMap = dbMap.getTable(getTableRole());
tMap.setPrimaryKeyMethod("idbroker_table");
tMap.setPrimaryKeyMethodInfo(tMap.getName()); /*ADDED*/
................
tMap = dbMap.getTable(getTablePermission());
tMap.setPrimaryKeyMethod("idbroker_table");
tMap.setPrimaryKeyMethodInfo(tMap.getName()); /*ADDED*/
................
tMap = dbMap.getTable(getTableJobentry());
tMap.setPrimaryKeyMethod("idbroker_table");
tMap.setPrimaryKeyMethodInfo(tMap.getName()); /*ADDED*/
................
}
Pere Torrodellas
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Security exception with Oracle
Posted by John McNally <jm...@collab.net>.
i reapplied my patch after the security branch was merged, so that is in
place. I will try to look further, but am quite swamped at the moment.
Please submit patches if you get it working.
John McNally
Pere Torrodellas wrote:
>
> >----- Mensaje original -----
> >De: John McNally <jm...@collab.net>
> >Para: <tu...@jakarta.apache.org>
> >Enviado: martes 17 de abril de 2001 20:21
> >Asunto: Re: Security exception with Oracle
> >
>
> > No the problem is not being handled some other way. It appears the
> > first security branch was taken using revision 1.8 then the security
> > branch was done again with revision 1.9. But I assume the version 1.8
> > was copied over the latest one. I guess it will have to be sorted out
> > after the merge unless jason or jon would like to apply a patch
> against
> > the branch (that you supply).
> >
> > John McNally
>
> John,
>
> I was finally able to test PermissionPeer 1.9 (the old class was being
> loaded from some strange and IMO wrong place; I'll try to investigate
> this later).
>
> This time I got a new exception, caused ultimately by the fact that
> TableMap.getPrimaryKeyMethodInfo() returns null when invoked in
> BasePeer.doInsert() for Security tables. I looked into
> TurbineMapBuilder, and it seems that the Security TableMaps pkInfo
> attribute is not being set. Shouldn't it be initialized there?
>
> Not being familiar with Turbine source maintenance rules, I didn't
> completely understand your last message. I just hope that your
> correction, supposing that everything will eventually work OK, will not
> be lost.
>
> Thanks,
>
> Pere Torrodellas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Silly DynamicURI question
Posted by John McNally <jm...@collab.net>.
That would be how to do it, though I think it might belong in the
template. If velocity is having problems, a method could be added to
TemplateLink
Magnús Þór Torfason wrote:
>
> I need to create duris that point to a <a name="myname"> tag.
>
> What I am doing now, is:
>
> return myDuri.toString() + "#myname";
>
> I can't seem to find a better way to do this with the DynamicURI class, and
> am wondering if there is one.
>
> Magnus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Silly DynamicURI question
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/18/01 3:12 AM, "Magnús Þór Torfason" <ma...@handtolvur.is> wrote:
> I need to create duris that point to a <a name="myname"> tag.
>
> What I am doing now, is:
>
> return myDuri.toString() + "#myname";
>
> I can't seem to find a better way to do this with the DynamicURI class, and
> am wondering if there is one.
>
> Magnus
You don't need to have the session id appended to a link like that because a
connection is not made back to the server when a link like that is
clicked...
So, you don't need to dynamicuri that at all...just do:
return "foo.vm#myname";
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Silly DynamicURI question
Posted by Magnús Þór Torfason <ma...@handtolvur.is>.
I need to create duris that point to a <a name="myname"> tag.
What I am doing now, is:
return myDuri.toString() + "#myname";
I can't seem to find a better way to do this with the DynamicURI class, and
am wondering if there is one.
Magnus
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Security exception with Oracle
Posted by Pere Torrodellas <pt...@fihoca.com>.
>----- Mensaje original -----
>De: John McNally <jm...@collab.net>
>Para: <tu...@jakarta.apache.org>
>Enviado: martes 17 de abril de 2001 20:21
>Asunto: Re: Security exception with Oracle
>
> No the problem is not being handled some other way. It appears the
> first security branch was taken using revision 1.8 then the security
> branch was done again with revision 1.9. But I assume the version 1.8
> was copied over the latest one. I guess it will have to be sorted out
> after the merge unless jason or jon would like to apply a patch
against
> the branch (that you supply).
>
> John McNally
John,
I was finally able to test PermissionPeer 1.9 (the old class was being
loaded from some strange and IMO wrong place; I'll try to investigate
this later).
This time I got a new exception, caused ultimately by the fact that
TableMap.getPrimaryKeyMethodInfo() returns null when invoked in
BasePeer.doInsert() for Security tables. I looked into
TurbineMapBuilder, and it seems that the Security TableMaps pkInfo
attribute is not being set. Shouldn't it be initialized there?
Not being familiar with Turbine source maintenance rules, I didn't
completely understand your last message. I just hope that your
correction, supposing that everything will eventually work OK, will not
be lost.
Thanks,
Pere Torrodellas
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Security exception with Oracle
Posted by John McNally <jm...@collab.net>.
No the problem is not being handled some other way. It appears the
first security branch was taken using revision 1.8 then the security
branch was done again with revision 1.9. But I assume the version 1.8
was copied over the latest one. I guess it will have to be sorted out
after the merge unless jason or jon would like to apply a patch against
the branch (that you supply).
John McNally
Pere Torrodellas wrote:
>
> ----- Mensaje original -----
> De: John McNally <jm...@collab.net>
> Para: <tu...@jakarta.apache.org>
> Enviado: jueves 12 de abril de 2001 20:32
> Asunto: Re: Security exception with Oracle
> >
> > I modified the buildCriteria methods for Group,Role, and Permission
> > Peers to not add the primary key column for new objects. Let me know
> if
> > this helps you. Hope it does not break anyone's workarounds.
> >
> > John McNally
>
> Thanks John. I didn't answer earlyer because both Friday and Monday were
> holydays here :-)
>
> Unfortunately, today I'm unable to get my webapp to use your version of
> PermissionPeer when I put it in the Turbine jar. It's getting some old
> version of the class from somewhere, but I can't find out why. Maybe the
> holydays were too much relax
>
> Anyway, I noticed that in the last CVS version (1.9.4.1) your fix has
> been removed in buildCriteria() and the XXX_ID is again added
> unconditionally. Is the problem being handled in some other way?
>
> Pere Torrodellas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Security exception with Oracle
Posted by Pere Torrodellas <pt...@fihoca.com>.
----- Mensaje original -----
De: John McNally <jm...@collab.net>
Para: <tu...@jakarta.apache.org>
Enviado: jueves 12 de abril de 2001 20:32
Asunto: Re: Security exception with Oracle
>
> I modified the buildCriteria methods for Group,Role, and Permission
> Peers to not add the primary key column for new objects. Let me know
if
> this helps you. Hope it does not break anyone's workarounds.
>
> John McNally
Thanks John. I didn't answer earlyer because both Friday and Monday were
holydays here :-)
Unfortunately, today I'm unable to get my webapp to use your version of
PermissionPeer when I put it in the Turbine jar. It's getting some old
version of the class from somewhere, but I can't find out why. Maybe the
holydays were too much relax
Anyway, I noticed that in the last CVS version (1.9.4.1) your fix has
been removed in buildCriteria() and the XXX_ID is again added
unconditionally. Is the problem being handled in some other way?
Pere Torrodellas
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Security exception with Oracle
Posted by John McNally <jm...@collab.net>.
Pere Torrodellas wrote:
>
...
> By comparing the Security inserts logic to the example webapp (RDF),
> whose inserts work with similar definitions, I've found the main
> difference that apparently confirms my suspicions:
>
> While PermissionPeer.buildCriteria(permission) unconditionally adds the
> PERMISSION_ID key to the criteria (see description above),
> RdfBasePeer.buildCriteria(rdf) only adds RDF_ID if the object is not
> new. So, for an insert the RDF_ID is not added and
> BasePeer.doInsert(criteria) dutifully generates an id for the new object
> by calling the IdBroker, and this leads to a correct DB insert.
>
I modified the buildCriteria methods for Group,Role, and Permission
Peers to not add the primary key column for new objects. Let me know if
this helps you. Hope it does not break anyone's workarounds.
John McNally
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Security exception with Oracle
Posted by Pere Torrodellas <pt...@fihoca.com>.
Hello,
Sorry if this message is getting too long; I'm just trying to add as
much information as I'm able to get to easy the task of whoever is able
to further diagnose the problem.
> > The Flux part in the peer application example of TDK 1.1a12 throws
an
> > exception when using Security to insert new elements in Oracle
tables.
> > Both retrieves and updates work OK. Inserts also work when using
MySql
> > instead of Oracle (no, I can't just stick to MySql ;-)
> >
> > The exception says that NULL has been specified for the ID column
> > (PERMISSION_ID, ROLE_ID,...). This seems to point to the procedure
to
> > get primary keys, right?
> >
> > By reproducing the code up to BasePeer.doInsert() in the case of a
> > Permission, I've seen that the criteria that is passed to
> > insertOrUpdateRecord() has indeed
> TURBINE_PERMISSION.PERMISSION_ID=null.
> >
> > Note that inserts work all right for the example RDF table, with
> > apparently the same definitions for the primary key.
> >
> > Can someone suggest the reason for this error? Thanks!
> >
> > Pere Torrodellas
>
> As far as I've been able to follow the Security code, this is what
seems
> to be happening in the case of a Permission insert:
>
> - FluxPermissionAction.doInsert() creates a new Permission and sets
its
> attributes with the RunData values. The only attribute set is the name
> specified by the user. It calls TurbineSecurity.addPermission(), which
> just invokes DBSecurityService.addPermission().
>
> - DBSecurityService.addPermission() builds a Criteria with
> PermissionPeer.buildCriteria(permission). This adds to the Criteria
the
> PERMISSION_ID key with the permission.getPrimaryKey() value. This is
> null, because nobody has set it. PermissionPeer.doInsert(criteria) is
> invoked, which is in fact a BasePeer method.
>
> - To find out if an id has to be generated, BasePeer looks for the
> primary key name in the criteria. In this case it's there, but the
value
> (which is null) is not checked. Since it's there, no new id is
generated
> and the insert is called, which leads to the exception described
above.
>
> Because Oracle doesn't provide auto-increment, I think that the value
> for the primary key should have been produced somewhere along the way
by
> using the corresponding sequence, probably BasePeer.
>
> Can someone please confirm this, or correct me?
>
> Thanks,
>
> Pere Torrodellas
By comparing the Security inserts logic to the example webapp (RDF),
whose inserts work with similar definitions, I've found the main
difference that apparently confirms my suspicions:
While PermissionPeer.buildCriteria(permission) unconditionally adds the
PERMISSION_ID key to the criteria (see description above),
RdfBasePeer.buildCriteria(rdf) only adds RDF_ID if the object is not
new. So, for an insert the RDF_ID is not added and
BasePeer.doInsert(criteria) dutifully generates an id for the new object
by calling the IdBroker, and this leads to a correct DB insert.
Hope this helps.
Pere Torrodellas
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Security exception with Oracle
Posted by Pere Torrodellas <pt...@fihoca.com>.
----- Mensaje original -----
De: Pere Torrodellas <pt...@fihoca.com>
Para: <tu...@jakarta.apache.org>
Enviado: martes 10 de abril de 2001 17:16
Asunto: Security exception with Oracle
> The Flux part in the peer application example of TDK 1.1a12 throws an
> exception when using Security to insert new elements in Oracle tables.
> Both retrieves and updates work OK. Inserts also work when using MySql
> instead of Oracle (no, I can't just stick to MySql ;-)
>
> The exception says that NULL has been specified for the ID column
> (PERMISSION_ID, ROLE_ID,...). This seems to point to the procedure to
> get primary keys, right?
>
> By reproducing the code up to BasePeer.doInsert() in the case of a
> Permission, I've seen that the criteria that is passed to
> insertOrUpdateRecord() has indeed
TURBINE_PERMISSION.PERMISSION_ID=null.
>
> Note that inserts work all right for the example RDF table, with
> apparently the same definitions for the primary key.
>
> Can someone suggest the reason for this error? Thanks!
>
> Pere Torrodellas
As far as I've been able to follow the Security code, this is what seems
to be happening in the case of a Permission insert:
- FluxPermissionAction.doInsert() creates a new Permission and sets its
attributes with the RunData values. The only attribute set is the name
specified by the user. It calls TurbineSecurity.addPermission(), which
just invokes DBSecurityService.addPermission().
- DBSecurityService.addPermission() builds a Criteria with
PermissionPeer.buildCriteria(permission). This adds to the Criteria the
PERMISSION_ID key with the permission.getPrimaryKey() value. This is
null, because nobody has set it. PermissionPeer.doInsert(criteria) is
invoked, which is in fact a BasePeer method.
- To find out if an id has to be generated, BasePeer looks for the
primary key name in the criteria. In this case it's there, but the value
(which is null) is not checked. Since it's there, no new id is generated
and the insert is called, which leads to the exception described above.
Because Oracle doesn't provide auto-increment, I think that the value
for the primary key should have been produced somewhere along the way by
using the corresponding sequence, probably BasePeer.
Can someone please confirm this, or correct me?
Thanks,
Pere Torrodellas
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org