Integrating with a website

19 views
Skip to first unread message

Matthew Marshall

unread,
Dec 15, 2008, 4:04:56 PM12/15/08
to try...@googlegroups.com
I will be developing a website (with python) that will need to integrate
with tryton. I haven't seen any information on doing this, so I guess I
need to ask here :)

My first choice would be to import trytond and use the OSV classes
directly. Would there be any problem with that? Does trytond expect to
have only one process accessing the db? I read something about threads
sharing caches... it sounds like multiple processes might have cache
problems.

My second choice would be to have my web processes connect to trytond as
a client. After a little looking around, it looks like importing
tryton.rpc would be all that's needed?

Are there any examples available for doing this? How would I (for
example) get the address of a party? My first guess was to call
rpc.execute("object", "execute", "party.party", "address_get", party_id)
but that doesn't work.

Thanks :)

MWM

Bertrand Chenal

unread,
Dec 16, 2008, 1:58:37 PM12/16/08
to try...@googlegroups.com
Le Mon, 15 Dec 2008 15:04:56 -0600,
Matthew Marshall <mat...@matthewmarshall.org> a écrit :

Hi,

Tryton allow to easily use the OSV classes directly, like this:

####
import sys, os
TRYTOND_PATH = '/home/bch/hg/trytond'
DIR = os.path.abspath(os.path.normpath(os.path.join(TRYTOND_PATH,'trytond')))
if os.path.isdir(DIR):
sys.path.insert(0, os.path.dirname(DIR))
from trytond import pooler
from trytond.modules import register_classes
from trytond import wkf_service
import datetime
wkf_service.WorkflowService()
register_classes()
USER = 1
POOL_PROXY = {}
def get_db_pool(dbname=False):
if dbname not in POOL_PROXY:
POOL_PROXY[dbname] = pooler.get_db_and_pool(dbname)
return POOL_PROXY[dbname]
db, pool = get_db_pool('try')
cursor = db.cursor()
product_obj = pool.get('product.product')
product_ids = product_obj.search(cursor, USER, [], context=None)
for product in product_obj.browse(cursor, USER, product_ids, context=None):
print product.name
cursor.close()
###

And yes tryton is design to allow multiple instances to access the same db.


--
Bertrand Chenal

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email: bertran...@b2ck.com
Website: http://www.b2ck.com/

Cédric Krier

unread,
Dec 16, 2008, 2:08:16 PM12/16/08
to try...@googlegroups.com
On 16/12/08 19:58 +0100, Bertrand Chenal wrote:
>
> And yes tryton is design to allow multiple instances to access the same db.
>

But you must set multi_server to True in trytond.conf

--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59

Email: cedric...@b2ck.com
Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/

Matthew Marshall

unread,
Dec 16, 2008, 3:41:24 PM12/16/08
to try...@googlegroups.com

Thanks Bertrand. This is exactly what I need.

MWM

nads...@hotmail.com

unread,
Dec 17, 2008, 5:08:55 PM12/17/08
to Tryton
Adapting the code above for my object, I can create a new object and
print out its ID, but the create isn't getting committed to the
database. However, postgres is showing that myobj_vehicle_id_seq is
getting incremented...

...
db, pool = get_db_pool('try')
cursor = db.cursor()
vehicle_obj = pool.get('myobj.vehicle')
id = vehicle_obj.create(cursor, USER, {'name':'test'}, context=None)
print id
cursor.close()

Cédric Krier

unread,
Dec 17, 2008, 5:14:37 PM12/17/08
to try...@googlegroups.com

missing here:

cursor.commit()

> cursor.close()
>

--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59

nads...@hotmail.com

unread,
Dec 17, 2008, 5:43:48 PM12/17/08
to Tryton
Many thanks again Cedric!

Hartmut Goebel

unread,
Dec 22, 2008, 1:31:48 PM12/22/08
to try...@googlegroups.com
Bertrand Chenal schrieb:

> Tryton allow to easily use the OSV classes directly, like this:

Where is security left here? I can not see any access control or login
in this code.

--
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP

Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de

Cédric Krier

unread,
Dec 22, 2008, 6:56:43 PM12/22/08
to try...@googlegroups.com
On 22/12/08 19:31 +0100, Hartmut Goebel wrote:
> Bertrand Chenal schrieb:
>
> > Tryton allow to easily use the OSV classes directly, like this:
>
> Where is security left here? I can not see any access control or login
> in this code.
>

If you are on the server and have access to the database, there is no
noeed of security check nor login mecanism.

--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59

Hartmut Goebel

unread,
Dec 23, 2008, 3:43:13 AM12/23/08
to try...@googlegroups.com
Cédric Krier schrieb:

> On 22/12/08 19:31 +0100, Hartmut Goebel wrote:
>> Bertrand Chenal schrieb:
>>
>>> Tryton allow to easily use the OSV classes directly, like this:
>> Where is security left here? I can not see any access control or login
>> in this code.
>>
>
> If you are on the server and have access to the database, there is no
> noeed of security check nor login mecanism.
>

This is exactly what I mean: An application accessing OSV directly
bypasses access control. Thus such an application has to implement the
access control again by itself. I doubt that this is a good thing.

Or to say it the other way round: It's a very, very bad way to implement
applications accessing the OSV directly, since this disables access
control. This is a major security risk, esp. since we are dealing with
an ERP system.

Carlos Perelló Marín

unread,
Dec 23, 2008, 4:17:31 AM12/23/08
to try...@googlegroups.com
El mar, 23-12-2008 a las 09:43 +0100, Hartmut Goebel escribió:
> Cédric Krier schrieb:
> > On 22/12/08 19:31 +0100, Hartmut Goebel wrote:
> >> Bertrand Chenal schrieb:
> >>
> >>> Tryton allow to easily use the OSV classes directly, like this:
> >> Where is security left here? I can not see any access control or login
> >> in this code.
> >>
> >
> > If you are on the server and have access to the database, there is no
> > noeed of security check nor login mecanism.
> >
>
> This is exactly what I mean: An application accessing OSV directly
> bypasses access control. Thus such an application has to implement the
> access control again by itself. I doubt that this is a good thing.
>
> Or to say it the other way round: It's a very, very bad way to implement
> applications accessing the OSV directly, since this disables access
> control. This is a major security risk, esp. since we are dealing with
> an ERP system.

>From my point of view, is a matter of using the authentication
infrastructure in Tryton itself. Anyway, what's the use case for your
application? My knowledge about Tryton is quite limited, but with my
experience in other applications that allow this kind of access, I think
you are not using the correct infrastructure.

For instance, a script that sends emails based on some information from
Tryton or a synchronization tool from an external source (an online
shop, etc...), direct access is ideal, because it's a maintenance task
and your development code is what limits its permissions.

However, a web application that uses Tryton as its backed and that
integrates also with its user database, makes more sense to connect
using the XML-RPC interface which provides you with authentication. If
your external application is not using the Tryton's user database, it
makes no sense to use its permission system, because your code will be
the one limiting what those users will be able to do in the system.

Again, I'm not a Tryton expert (yet), but from my developer point of
view, I don't see a problem with the fact that direct python access
doesn't have an implicit security infrastructure.

Cheers.

--
Carlos Perelló Marín
[P+] SERVICIOS PROFESIONALES
mailto:car...@pemas.es || mailto:car...@gnome.org
Alicante - Spain

Bertrand Chenal

unread,
Dec 23, 2008, 4:42:17 AM12/23/08
to try...@googlegroups.com
Le Tue, 23 Dec 2008 09:43:13 +0100,
Hartmut Goebel <h.go...@goebel-consult.de> a écrit :

> Cédric Krier schrieb:
> > On 22/12/08 19:31 +0100, Hartmut Goebel wrote:
> >> Bertrand Chenal schrieb:
> >>
> >>> Tryton allow to easily use the OSV classes directly, like this:
> >> Where is security left here? I can not see any access control or login
> >> in this code.
> >>
> >
> > If you are on the server and have access to the database, there is no
> > noeed of security check nor login mecanism.
> >
>
> This is exactly what I mean: An application accessing OSV directly
> bypasses access control. Thus such an application has to implement the
> access control again by itself. I doubt that this is a good thing.

Accessing OSV bypass the authentication step with login/password, but rules
(ir.rule) and model access (ir.model.access) are not bypassed (as long as
search/browse/read/write/create and the right user id are used). Of course
there is not access control if one use the "cursor.execute" method to access
the db directly.

As said on another answer it depends on what you plan to do with it, but it's
important to know pro (no rpc, same address space, ease of use)and cons (one
should take care of security/authentication) of this method.


"with great power comes great responsibility"
Spider-man


And ... Merry Christmas !


--
Bertrand Chenal

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59

Email: bertran...@b2ck.com
Website: http://www.b2ck.com/

Cédric Krier

unread,
Dec 23, 2008, 4:43:21 AM12/23/08
to try...@googlegroups.com
On 23/12/08 09:43 +0100, Hartmut Goebel wrote:
> Cédric Krier schrieb:
> > On 22/12/08 19:31 +0100, Hartmut Goebel wrote:
> >> Bertrand Chenal schrieb:
> >>
> >>> Tryton allow to easily use the OSV classes directly, like this:
> >> Where is security left here? I can not see any access control or login
> >> in this code.
> >>
> >
> > If you are on the server and have access to the database, there is no
> > noeed of security check nor login mecanism.
> >
>
> This is exactly what I mean: An application accessing OSV directly
> bypasses access control. Thus such an application has to implement the
> access control again by itself. I doubt that this is a good thing.
>
> Or to say it the other way round: It's a very, very bad way to implement
> applications accessing the OSV directly, since this disables access
> control. This is a major security risk, esp. since we are dealing with
> an ERP system.
>

It depends of the purpose of the script.
And in the script, you must use one user id so you will have the access
right of this id. So you will not have the password check but all the
other stuff are still there.
And as I say previously, if you have access to the database, you can do
*every things* with or without OSV.

Reply all
Reply to author
Forward
0 new messages