On Thu, Apr 7, 2016 at 5:04 PM, Mark Wieder wrote:
> Kids... don't try this at home...
Err, yes.
One of the reasons I made no effort to insure that it was correct!
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-li
Gave that a whirl with col4=? and a bind parameter of "*" OR 1=1 for it and
it returned no data. Pretty sure it takes the whole string as a search
value for col4.
On Thu, Apr 7, 2016 at 7:19 PM Mark Wieder wrote:
> On 04/07/2016 06:41 PM, Peter Haworth wrote:
> > Right, I think I have that co
On 04/07/2016 06:41 PM, Peter Haworth wrote:
Right, I think I have that covered since I prepare and bind the data in
separate steps using the php functions for those purposes.
So instead of assembling a SELECT statement like this:
SELECT col1,col2,col3 FROM table WHERE col4=''
... and then exe
Right, I think I have that covered since I prepare and bind the data in
separate steps using the php functions for those purposes.
So instead of assembling a SELECT statement like this:
SELECT col1,col2,col3 FROM table WHERE col4=''
... and then executing it directly, I prepare this statement:
On 04/07/2016 04:31 PM, Dr. Hawkins wrote:
I've probably hacked up the syntax, and there might be an intermediate
query needed to get the table name, but something like this grabs all your
data and deletes it while you thought you were doing an INSERT or such.
Kids... don't try this at home...
On Wed, Apr 6, 2016 at 1:03 PM, Peter Haworth wrote:
> Now you've got me worried! I had the impression that since the php scripts
> run on my server and access the mySQL database on the same server, there
> wouldn't be any sql injection issues, particularly since I never send any
> SQL statement
Peter:
Glad my stack was a help. Be careful with my mySQL php scripts. The examples
are meant only as starting points. They allow for injection attacks if the
inputs aren’t carefully filtered in Livecode before being formed into the
query. You could modify the php so that each script does only a
On 04/06/2016 02:12 PM, Peter Haworth wrote:
I just can't be bothered replying to that...
On Wed, Apr 6, 2016 at 1:55 PM Mark Wieder wrote:
On 04/06/2016 01:03 PM, Peter Haworth wrote:
I'm just as lazy as the next developer
Oh, I could probably give you a run for your money in the lazy ra
I just can't be bothered replying to that...
On Wed, Apr 6, 2016 at 1:55 PM Mark Wieder wrote:
> On 04/06/2016 01:03 PM, Peter Haworth wrote:
>
> > I'm just as lazy as the next developer
>
> Oh, I could probably give you a run for your money in the lazy race any
> day.
>
> --
> Mark Wieder
>
On 04/06/2016 01:03 PM, Peter Haworth wrote:
I'm just as lazy as the next developer
Oh, I could probably give you a run for your money in the lazy race any
day.
--
Mark Wieder
ahsoftw...@gmail.com
___
use-livecode mailing list
use-livecode@lis
Hi Mark,
Now you've got me worried! I had the impression that since the php scripts
run on my server and access the mySQL database on the same server, there
wouldn't be any sql injection issues, particularly since I never send any
SQL statements from my client app to the server.
I'm just as lazy
This is where it gets interesting. My original plan was to directly
connect to mySQL from Livecode using the variableslist parameter to the
various Livecode db functions, which should protect against sql injection.
To be honest, I don't recall why I went away from that plan in favor of
middleware.
On 04/06/2016 10:35 AM, Ray wrote:
Yeah, my expectation is that we'll avoid injection issues using the PHP
middleware.
No, sql injection is avoided by proper coding and by paying attention.
PHP as a platform is notoriously subject to sql injection errors mostly
because its ease of use encour
I do remember a post from you about not being able to send multiple
statements to SQL in one Livecode call, and also I'm pretty sure it was
confirmed. so that's probably what you're thinking of.
On Wed, Apr 6, 2016 at 10:17 AM Dr. Hawkins wrote:
> On Wed, Apr 6, 2016 at 9:42 AM, Peter Haworth
Very interesting. I've looked a little into postgreSQL, not that much.
I think we've pretty much decided to stick with mySQL for now, it should
work for our purpose, but you've peaked my interest in postgreSQL.
Many thanks for your input on this Richard!
On 4/6/2016 3:13 PM, Dr. Hawkins wrot
I'd actually be happy with emails if they included everything I need and
excluded unnecessary stuff, but we've had a lot of problems in the past
relying on general emails so we're going to try something which should
help guide our users to writing good bug reports.
On 4/6/2016 2:55 PM, EED-wp
On Wed, Apr 6, 2016 at 10:38 AM, Ray wrote:
> So Richard, what did you end up going with when neither sqLite nor mySQL
> worked out for you?
postgreSQL
It's more mature in some ways than mySQL, but more importantly, I can give
compound transaction (there's a 500+ statement query on client open
Ray
Good idea. I just get bug reports emailed to me. That's why I send the email by
accessing a php mail system on my server. That way the user doesn't have to
have email installed.
William Prothero
http://ed.earthednet.org
> On Apr 6, 2016, at 8:32 AM, Ray wrote:
>
> Richard - thanks for th
I haven't gotten that far into the database syntax and Livecode's
handling of it yet so I couldn't say, yet. But I'm sure I'll figure out
soon what, if any, Livecode's limitations are.
So Richard, what did you end up going with when neither sqLite nor mySQL
worked out for you?
On 4/6/2016
Yeah, my expectation is that we'll avoid injection issues using the PHP
middleware.
All in all, it seems like a pretty common need; to store on a server a
database that multiple users are going to be updating. I wish there
were some sort of a Livecode lesson which detailed several approaches
On Wed, Apr 6, 2016 at 9:42 AM, Peter Haworth wrote:
>
> mySQL does have transactions, as do all SQL implementations. They're part
> of the SQL spec. postGresql may well have advantages over mySQL but that
> isn't one of them.
>
Now I'm trying to remember: is it that livecdoe that can't succes
On Wed, Apr 6, 2016 at 8:32 AM, Ray wrote:
> Richard - thanks for this advice. It's really quite helpful. We've
> abandoned the sqLite idea but I think mySQL should work fine. The purpose
> of this database is to maintain an index of bug reports. The bug reports
> themselves are actually Livec
Hi Ray,
Lots of things for you to think about! As someone else mentioned, I
thought you were using a network file system rather than a web server.
Just to set the record straight on a couple of things.
mySQL does have transactions, as do all SQL implementations. They're part
of the SQL spec. p
Richard - thanks for this advice. It's really quite helpful. We've
abandoned the sqLite idea but I think mySQL should work fine. The
purpose of this database is to maintain an index of bug reports. The bug
reports themselves are actually Livecode stacks. The database will
serve as an index
On Wed, Apr 6, 2016 at 6:05 AM, Ray wrote:
> I thought of downloading it, updating it, and then putting it back on the
> server but that wouldn't work if two users simultaneously did so. Since
> I'll have many users using the database simultaneously everything has to be
> done on the server. I
Bill thanks for sharing this with me. I've downloaded it and I'm
looking into now. I'll let you know how it works out.
On 4/6/2016 10:26 AM, Earthednet-wp wrote:
Ray,
I have a stack for MySQL implementation that might help you get started, since
you are thinking of using php as middleware. I
Ray,
I have a stack for MySQL implementation that might help you get started, since
you are thinking of using php as middleware. It's at
http://es.earthednet.org/SoftwareForEducation
Scroll to the bottom of the page.
Good luck.
Bill
William Prothero
http://es.earthednet.org
> On Apr 6, 2016, at
Thanks for your confirmation on this, Mike. We'll continue with the PHP
middleware plan. It seems to be industry standard and it makes sense,
especially from a security standpoint.
On 4/6/2016 10:15 AM, Mike Bonner wrote:
Actually, you CAN connect directly to to mysql server (its actually a
Thanks Mike. I've used Andre's solutions a number of times and they've
always worked really well. I wasn't aware of this one.
On 4/6/2016 10:21 AM, Mike Bonner wrote:
On an "LC server" side note, andre garzias dblib is really helpful. It
might be possible to build up your query locally using
On an "LC server" side note, andre garzias dblib is really helpful. It
might be possible to build up your query locally using dblib, then send the
resulting array to the server that also uses dblib, set the array there and
execute the action. (dblib works great) I think it will work with either
Actually, you CAN connect directly to to mysql server (its actually a
server in its own right) if you set things up that way. You have to change
where connections are allowed from but honestly, you're still better off
using middleware. This way you can place any files with sensitive data
(password
abase theDbId -- close it or I won't be able to
copy
it
to the server
I then copy the local database file to a remote server and make
sure
all 9 permissions are checked (777).
I now load the well-tested server path into the variable dbPath
and
try this:
put revOpenDatabase(&quo
to:use-livecode-boun...@lists.runrev.com] On Behalf
Of Ray
Sent: Tuesday, April 05, 2016 10:51 PM
To: use-livecode@lists.runrev.com
Subject: Re: Error: Unable to open the database file
Mike - if I set the folder to the area I've set up to work with this,
"http://54.210.118.224/Downloads/&
Subject: Re: Error: Unable to open the database file
Mike - if I set the folder to the area I've set up to work with this,
"http://54.210.118.224/Downloads/";, I get "can't open that directory"
returned in the result. I can read files at that location but I get an
&qu
Mike Bonner wrote:
> You can write your own middleware using LC server if you have it set
> up on your remote.
Does anyone here know of a good tutorial on using LC Server as DB
middleware?
This comes up a lot, and it would be great to have a URL to pass around.
Related: anyone here using An
/2016 3:38 PM, Devin Asay wrote:
>>>>>>>>>
>>>>>>>>> Ray,
>>>>>>>>>
>>>>>>>>>> You may have moved your DB file from a system that is not case
>>>>>>>>>>
>>>>>>>
ugs(Name char(50), Date char(50))" into
myQuery
revExecuteSQL theDbId,myQuery -- the local database file is
no 2
K
revCloseDatabase theDbId -- close it or I won't be able to
copy
it
to the server
I then copy the local database file to a remote server and ma
>>
>>>>>>>> On Apr 5, 2016, at 12:39 PM, Ray wrote:
>>>>>>>>
>>>>>>>>> ...one other note. I'm guessing calls to sqLite need drivers.
>>>>>>>>> These
>>>>>>>>>
>
copy the local database file to a remote server and make sure
all 9 permissions are checked (777).
I now load the well-tested server path into the variable dbPath and
try this:
put revOpenDatabase("sqLite",dbPath) into myResult
but all I get back is:
Error: Unable to open t
make sure
all 9 permissions are checked (777).
I now load the well-tested server path into the variable dbPath and
try this:
put revOpenDatabase("sqLite",dbPath) into myResult
but all I get back is:
Error: Unable to open the database file
Suggestions?
_
these
>>>>>>>
>>>>>> drivers on my own server?
>>>>>
>>>>>> On 4/5/2016 1:18 PM, Ray wrote:
>>>>>>>
>>>>>>>> I've never worked with sqLite databases before but it appears I
>&g
loseDatabase theDbId -- close it or I won't be able to copy
it
to the server
I then copy the local database file to a remote server and make sure
all 9 permissions are checked (777).
I now load the well-tested server path into the variable dbPath and
try this:
put revOpenDataba
) into theDbId
> >> -- this creates a zero K local database file
> >>>>> put "CREATE TABLE bugs(Name char(50), Date char(50))" into
> myQuery
> >>>>> revExecuteSQL theDbId,myQuery -- the local database file is no 2
> K
>
ake sure
all 9 permissions are checked (777).
I now load the well-tested server path into the variable dbPath and
try this:
put revOpenDatabase("sqLite",dbPath) into myResult
but all I get back is:
Error: Unable to open the database file
Suggestions?
___
me char(50), Date char(50))" into myQuery
> >>>revExecuteSQL theDbId,myQuery -- the local database file is no 2 K
> >>>
> >>>revCloseDatabase theDbId -- close it or I won't be able to copy it
> to the server
> >>>
> &
nDatabase("sqLite",dbPath) into myResult
but all I get back is:
Error: Unable to open the database file
Suggestions?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage yo
er and make sure all 9
>> permissions are checked (777).
>>
>> I now load the well-tested server path into the variable dbPath and try this:
>> put revOpenDatabase("sqLite",dbPath) into myResult
>>
>> but all I get back is:
>> Error: Unable
't be able to copy it
to the server
I then copy the local database file to a remote server and make sure
all 9 permissions are checked (777).
I now load the well-tested server path into the variable dbPath and
try this:
put revOpenDatabase("sqLite",dbPath) into myResult
but a
to a remote server and make sure all
9 permissions are checked (777).
I now load the well-tested server path into the variable dbPath and try
this:
put revOpenDatabase("sqLite",dbPath) into myResult
but all I get back is:
Error: Unable to open the database file
Suggestions?
_
49 matches
Mail list logo
