Thanks Peter, I have updated the bug report to ask the question as you
suggested.
With respect, unless revdb is an lc script, it's highly unlikely I would
have the skills to change it.
On Sat, Aug 15, 2015 at 1:29 PM Peter TB Brett
wrote:
> On 2015-08-15 18:30, Peter Haworth wrote:
> > Excellen
On 2015-08-15 18:30, Peter Haworth wrote:
Excellent, thank you Peter. Had not had a chance to look at the
release
notes for those two versions yet. It doesn't look like the referenced
bug
report 14289 has been updated to reflect this.
Couple of follow up questions.
Has the sqlite user authe
Excellent, thank you Peter. Had not had a chance to look at the release
notes for those two versions yet. It doesn't look like the referenced bug
report 14289 has been updated to reflect this.
Couple of follow up questions.
Has the sqlite user authentication module been enabled in this version
On Fri, Aug 14, 2015 at 4:50 PM, Monte Goulding wrote:
> I believe Mark Wieder had a good look at revDB and decided to stop looking
> ;-)
Was it Mark that warned me off a few weeks ago when I wanted to add a
couple of lines to enable ssl for postgres?
--
Dr. Richard E. Hawkins, Esq.
(702) 5
On 2015-08-14 23:31, Peter Haworth wrote:
The SQLite library supplied with LC is months old, and a large
number of bug fixes and several useful enhancements are missing.
In LiveCode 6.7.7-rc-2 and LiveCode 7.1.0-rc-1, we provide libSQLite
3.8.10.2, released on 2015-05-20.
On 08/14/2015 04:50 PM, Monte Goulding wrote:
I believe Mark Wieder had a good look at revDB and decided to stop looking ;-)
Yeah, partly I ran away screaming after poking around under the hood,
and partly the rev team in 2006 declared all the db bugs in bugzilla as
'resolved' in favor of a
> On 15 Aug 2015, at 10:35 am, Richard Gaskin
> wrote:
>
> Am I being too optimistic here?
Yes it should be possible to automate updates, their CI server should tell them
if the automatic update failed for some reason and then they can jump in
manually. I’d be surprised if they weren’t plann
Monte Goulding wrote:
> BTW I’ve almost definitely oversimplified this. With the number of
> platforms LC is deployed on I’d be surprised if there isn’t some
> manual tweaking of project/make files required quite often with a
> new version of a library. Then when you consider the number of
> libra
> On 15 Aug 2015, at 9:50 am, Monte Goulding
> wrote:
>
>> There's gotta be a way to automate that
>
> Well yes there is, these things should be submodules of the engine repo so
> that keeping them updated should be as simple as checking out their most
> recent tagged release. Not all th
> On 15 Aug 2015, at 9:49 am, Richard Gaskin wrote:
>
> We need better integration with upstreams. In addition to SQLite, there's
> Skia and others. At any time any one of them may have bug fixes that we'll
> want to include ASAP.
>
> Anyone here review the revDB externals for SQlite deeply
Peter Haworth wrote:
I just thought of a downside to using lc as db middleware if I choose to
use SQLite. The SQLite library supplied with LC is months old, and a large
number of bug fixes and several useful enhancements are missing. I have
filed QCC reports about this and also asked for the a
I just thought of a downside to using lc as db middleware if I choose to
use SQLite. The SQLite library supplied with LC is months old, and a large
number of bug fixes and several useful enhancements are missing. I have
filed QCC reports about this and also asked for the ability to load our own
s
Peter Haworth wrote:
> Next decision - php or lc server. lc server is attractive since
> I already know the language but suffers from the drawback that not
> many web hosts support it.
Any Web server that supports CGI can use LiveCode as easily as Ruby,
Perl, or any other CGI.
And IMNSHO, an
Thanks Todd, that sounds very interesting. I will email you off list for
more info.
On Fri, Aug 14, 2015 at 11:28 AM Todd Fabacher wrote:
> I have used SQLite on a database server, but it has it's limitations. mySQL
> is the way to go for a long term solution. It is actually MUCH better when
>
Sure, I can certainly see a networked db would be necessary in that
scenario but seems like for a simple, in-house system with a small number
of users, could be useful just because of it's simplicity.
On Fri, Aug 14, 2015 at 11:16 AM Peter TB Brett
wrote:
> On 2015-08-14 19:31, Peter Haworth wro
I have used SQLite on a database server, but it has it's limitations. mySQL
is the way to go for a long term solution. It is actually MUCH better when
you start to go over everything that is needed for a true web server such
as backup, load balance, multi user transactions and a VERY long list.
We
On 2015-08-14 19:31, Peter Haworth wrote:
Next decision - php or lc server. lc server is attractive since I
already
know the language but suffers from the drawback that not many web hosts
support it.
Yes, that's exactly the trade-off that needs to be made! I don't think
there's any hard an
Thanks Peter, that is indeed an important consideration. I believe there
are ways to code around that but nevertheless the single connection
middleware method would certainly be less complicated.
I think I am now realizing the full implications of the direct and indirect
methods of connecting to
Ralph,
See Peter's comments about non-security considerations too.
Also note I have no security qualifications other than a mix of paranoia and a
sometimes suspicious mind.
> 3) The client uses https requests. I am assuming that the URL itself is
> encrypted so any of the commands to my web se
On 2015-08-13 19:16, Peter Haworth wrote:
What are the pluses and minuses you get from using php as a middleman
to
access a mySQL database on a server versus accessing the mySQL database
directly from LC?
There are good reasons other than security that you might want to
indirect your database
Dave,
Thanks for the clarifications.
I'm changing my app over to server side middleware using LC server and
opening one local connection to the MySQL DB.
My client/server model.
1) The LC server script has the DB username/password and no one can see
that. That protects the DB.
2) LC scripts
Thanks Dave. I think it's beginning to sink in.
In answer to your question, I never trust my users!
On Thu, Aug 13, 2015 at 4:17 PM Dave Cragg wrote:
>
> > On 13 Aug 2015, at 23:56, Peter Haworth wrote:
> >
> > Thanks Dave. That's good info.
> >
> > My questions are specifically related to m
> On 13 Aug 2015, at 23:56, Peter Haworth wrote:
>
> Thanks Dave. That's good info.
>
> My questions are specifically related to mySQL which is able to accept
> remote connections by design.
Sorry if I wasn't clear. I was suggesting that it's generally a bad idea to
allow remote connections.
On Thu, Aug 13, 2015 at 3:56 PM, Peter Haworth wrote:
> I do like the idea of only a single connection to the db from the server
> side script. But don't you then start getting into multiple thread issues
> for performance reasons?
>
I will be needing a persistent server for my remote clients,
Thanks Dave. That's good info.
My questions are specifically related to mySQL which is able to accept
remote connections by design.
I see your point about passing the credentials but, as mentioned to Bill,
doesn't opening the database connection using SSL take care of that? Same
for your point
Thanks Bill, it does make sense. But doesn't the use of SSL when opening
the database connection prevent outside interference with the SQL command?
Just trying to understand this before going down the wrong path :-)
On Thu, Aug 13, 2015 at 3:03 PM William Prothero
wrote:
> Peter:
> The answ
> On 13 Aug 2015, at 22:44, Peter Haworth wrote:
>
> I agree that SQL doesn't have much in the way of data sanitizing but
> Livecode does. I also agree that there must be a good reason why most of
> the world uses server side scripting, just trying to understand exactly
> what that is.
>
> I'v
Peter:
The answer to the question is “where does the security failure occur?” The weak
link is the transmission of the command from the local computer to the server.
If you tokenize the command at the local computer level, you still have the
problem. The remote server can be accessed by anybody
On Thu, Aug 13, 2015 at 10:16 AM, Peter Haworth wrote:
> What are the pluses and minuses you get from using php as a middleman to
> access a mySQL database on a server versus accessing the mySQL database
> directly from LC?
>
Also note that LiveCode can't handle compound commands with mySQL, whi
I agree that SQL doesn't have much in the way of data sanitizing but
Livecode does. I also agree that there must be a good reason why most of
the world uses server side scripting, just trying to understand exactly
what that is.
I've been under the impression that if I use the variableslist parame
Peter Haworth wrote:
It still seems to me that, once security matters are dealt with, the choice
of server side script versus direct connection is more a matter of
preferred application architecture more than anything else.
Ah, but there's the rub, "once security matters are dealt with".
Corre
Thanks BIll. I understand about the tokenization but Livecode can already
do that within a direct connection without a server side script and, at
least for mySQL, can open a direct connection using SSL.
It still seems to me that, once security matters are dealt with, the choice
of server side scr
Peter:
> I'm probably still not understanding this completely, but how do I protect
> against SQL injection attacks when using a server side interface? I can do
> that very easily from within Livecode by using the parameterized variables
> available with the revdbxxx calls but it seems like I woul
Thanks for all the inout. I should probably have phrased my question a
little differently and asked about the pros and cons of a sever side
interface versus a direct connection rather than referencing php
specifically. The php reference came about because of a recent post on its
use.
It appears t
Or even worse:
SELECT content FROM data WHERE user=;DROP TABLE data
On Thu, Aug 13, 2015 at 10:50 AM Mark Waddingham wrote:
>
> Here the input field is not being validated in anyway, nor is the value
> being escaped. This means that I am then free (as a user of the client)
> to put anything I
Mark Waddingham
> As a simple (rather stupid) example consider a client application
> which has a field which expects a number, and an output field.
>
> The user enters a number into the field and the client does a query
> to fetch a piece of data mapped to that number in the DB. e.g.
> query "
Here 'unsafe' means something which has come from the client via some
sort of user input without being vetted or checked.
I should clarify here that user input doesn't necessarily come from
input fields in a UI - it can come from any data passed from the client
to the server which originates f
Good question. Why is LC server instead of PHP not an option for you?
I
know this has been talked about on the list before but I still don't
have a
solid handle on this. I'm still am not clear on how SQL injection can
be
done with a direct MySQL connection using ssl. Also when using a web
serv
Peter,
Good question. Why is LC server instead of PHP not an option for you? I
know this has been talked about on the list before but I still don't have a
solid handle on this. I'm still am not clear on how SQL injection can be
done with a direct MySQL connection using ssl. Also when using a web
In general it is not advised to directly connect to databases over the Internet
and it is considered better practice to front your db access through an http
interface (which you could equally well implement in LC server running and
connecting locally to the db on the server).
One reason to do t
40 matches
Mail list logo
