Re: [sqlalchemy] Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Mike Bayer
On Fri, Mar 8, 2019 at 6:09 PM Walter Askew wrote: > > > > On Mar 8, 2019, at 11:57 AM, Mike Bayer wrote: > > this use is insecure and is not supported. SQLAlchemy's bound > parameter rendering is only intended for debugging and for special DDL > scenarios and should not be used for

Re: [sqlalchemy] contains_eager option on polymorphic joined query

2019-03-08 Thread Mike Bayer
On Fri, Mar 8, 2019 at 3:56 PM wrote: > > Hi everyone! > > I am trying to use the contains_eager option on a simple polymorphic query > that looks like: > > class Superclass(): > common_relationship = relationship('Common', ...) > discriminator_field = Column(String...) >

Re: [sqlalchemy] Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Walter Askew
> On Mar 8, 2019, at 11:57 AM, Mike Bayer wrote: > > this use is insecure and is not supported. SQLAlchemy's bound > parameter rendering is only intended for debugging and for special DDL > scenarios and should not be used for ordinary SQL statements passed to > a database. Would you

[sqlalchemy] Making Python3 list from set returned by SQL query

2019-03-08 Thread Rich Shepard
Two classes in the model have columns with values constrained to specific text strings; one table has two such columns, another table has one. Because new strings might be added to the lists of allowed values for that column each has the acceptable values as rows in a table rather than in a

[sqlalchemy] contains_eager option on polymorphic joined query

2019-03-08 Thread jay . chia
Hi everyone! I am trying to use the contains_eager option on a simple polymorphic query that looks like: class Superclass(): common_relationship = relationship('Common', ...) discriminator_field = Column(String...) __mapper_args__ = {'polymorphic_identity': 'superclass',

Re: [sqlalchemy] delete orphan unfavorite operations

2019-03-08 Thread Mike Bayer
On Fri, Mar 8, 2019 at 3:05 PM Conferency wrote: > > Thanks. > > I didn't use association proxy. > > > "because you can't add Tool to Person.tools". This is real code and I can > > directly append the tool instance. that will cause this error: sqlalchemy.orm.exc.FlushError: Attempting to flush

Re: [sqlalchemy] delete orphan unfavorite operations

2019-03-08 Thread Conferency
Thanks. I didn't use association proxy. > "because you can't add Tool to Person.tools". This is real code and I can directly append the tool instance. class Association(db.Model): ... id = db.Column(Integer, primary_key=True, index=True) tool_id = db.Column(Integer,

Re: [sqlalchemy] Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Mike Bayer
On Fri, Mar 8, 2019 at 2:00 PM Walt wrote: > > > > On Friday, March 8, 2019 at 12:19:54 PM UTC-6, Mike Bayer wrote: >> >> >> I've re-read your original request. If I am reading correctly, *you* >> are generating these values and passing them to an HTTP web service of >> some kind. In this

Re: [sqlalchemy] Re: Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread 'Van Klaveren, Brian N.' via sqlalchemy
As has been said, if you are generating the SQL, you will be fine so long as you use parameters and no blind string interpolation. This isn't really any different that any other API in that regard - obviously you don't want to allow a non-substituted first name field of the form `'; DROP TABLE

Re: [sqlalchemy] Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Mark Steward
My understanding is that this is untrusted data, providing a frontend to a DB, where the "connection" is actually an HTTP API. I'd be super cautious here, as there are loads of historic encoding issues with each database backend. Don't forget newlines and null bytes. If you can, whitelist a

Re: [sqlalchemy] Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Walt
On Friday, March 8, 2019 at 12:19:54 PM UTC-6, Mike Bayer wrote: > > > I've re-read your original request. If I am reading correctly, *you* > are generating these values and passing them to an HTTP web service of > some kind. In this scenario, there is no untrusted input, so there is > no

Re: [sqlalchemy] Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Mike Bayer
On Fri, Mar 8, 2019 at 10:31 AM Walter Askew wrote: > > > > On Mar 8, 2019, at 5:25 AM, Mike Bayer wrote: > > > SQL injection has to do with strings that are sent to the database > engine. from what you said above, it seems like you are generating > strings just to display them on a webpage? >

[sqlalchemy] Re: Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Jonathan Vanasco
On Friday, March 8, 2019 at 12:56:26 PM UTC-5, Walt wrote: > > Thanks, so the limitations the documentation is bringing up are more that > SQLAlchemy doesn't know how to bind the same variety of types as does the > DBAPI? > Hopefully I will get this write so Mike won't have to correct me...

[sqlalchemy] Re: Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Walt
On Friday, March 8, 2019 at 11:32:01 AM UTC-6, Jonathan Vanasco wrote: > > Do you control the HTTP API or is this someone else's system? > It's someone else's. I'm living in a world where folks have generated their SQL with regular old string processing & interpolation in Python because

[sqlalchemy] Re: Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Jonathan Vanasco
forgot to add: in your example: NEVER TRUST USER INPUT. you'll get a much better error and can fix problems when you don't trust them and try to sanitize stuff - (x > user_provided_value) + (x > int(user_provided_value)) # or float or whatever The stuff 'compile' generates won't

[sqlalchemy] Re: Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Jonathan Vanasco
Do you control the HTTP API or is this someone else's system? Does the API just execute the raw sql it is provided, and you're looking to generate that? What you want to do is pipe a SqlAlchemy query into a function that can compile it into the right statement for your database. Below is an

Re: [sqlalchemy] Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Walter Askew
> On Mar 8, 2019, at 5:25 AM, Mike Bayer wrote: >> > SQL injection has to do with strings that are sent to the database > engine. from what you said above, it seems like you are generating > strings just to display them on a webpage? No, I’m not displaying SQL strings on a webpage. I’m

Re: [sqlalchemy] delete orphan unfavorite operations

2019-03-08 Thread Mike Bayer
On Thu, Mar 7, 2019 at 4:46 PM Conferency wrote: > > Hi, I have 3 classes: two have many to many relationship between them, one is > association class. > > class Person: > ... > tools = relationship('Association', back_populates='user', lazy=True, > cascade='all, delete-orphan') > >

Re: [sqlalchemy] Security Implications of Directly Executing Queries Compiled to Strings

2019-03-08 Thread Mike Bayer
On Thu, Mar 7, 2019 at 4:47 PM Walt wrote: > > For some odd reasons, I'm in a situation where I don't have direct access to > a database, but I do have an HTTP API fronting the database which I can > submit SQL strings to and get results back from. I'd like to use SQLAlchemy > to generate the