Vincent Veyron schrieb am 19.04.2012 um 22:33 (+0200):
I see, I forgot to tell one step : once in the demo account, you see a
list a 'Dossiers' in the right part of the screen
Click into any 'dossier', the first one will do. Once inside, you'll see
the tabs at the top of the screen, choose
Le vendredi 20 avril 2012 à 11:55 +0200, Michael Ludwig a écrit :
element. So each type of document would have an associated server-side
handler that knows how to deal with it and what data to send back.
The problem with this solution is that it leads to a maintenance
nightmare, as these
Le jeudi 19 avril 2012 à 00:39 +0200, Michael Ludwig a écrit :
Got lost here, but your description makes sense even without the real
thing, so …
Not sure how you got lost, did you not find the site? the address is
below, in my signature. Then enter the demo account.
--
Vincent Veyron
Vincent Veyron schrieb am 19.04.2012 um 09:24 (+0200):
Le jeudi 19 avril 2012 à 00:39 +0200, Michael Ludwig a écrit :
Got lost here, but your description makes sense even without the
real thing, so …
Not sure how you got lost, did you not find the site? the address is
below, in my
Le jeudi 19 avril 2012 à 18:38 +0200, Michael Ludwig a écrit :
Did all that. Got lost at this point:
I couldn't find any persons or their info or Afficher les modèles.
These things simply weren't there.
I see, I forgot to tell one step : once in the demo account, you see a
list a
Vincent Veyron schrieb am 18.04.2012 um 02:11 (+0200):
Le mercredi 18 avril 2012 à 00:30 +0200, Michael Ludwig a écrit :
Maybe people can come up with more helpful
suggestions if you post a concrete example of what is cumbersome.
Sure, the app in my sig has a demo a account which you
Bonjour Vincent,
Vincent Veyron schrieb am 16.04.2012 um 22:21 (+0200):
I guess (in the message I forwarded to the list) Andreas is right,
though : the only way to be safe is to keep control of the query,
therefore keep it on the server.
I am doing this now, but passing parameters to the
Le mardi 17 avril 2012 à 20:10 +0200, Michael Ludwig a écrit :
Bonjour Vincent,
Vincent Veyron schrieb am 16.04.2012 um 22:21 (+0200):
I guess (in the message I forwarded to the list) Andreas is right,
though : the only way to be safe is to keep control of the query,
therefore keep it
To: Michael Ludwig
Cc: modperl@perl.apache.org
Subject: Re: Safe handling of an SQL query
Le mardi 17 avril 2012 à 20:10 +0200, Michael Ludwig a écrit :
Bonjour Vincent,
Vincent Veyron schrieb am 16.04.2012 um 22:21 (+0200):
I guess (in the message I forwarded to the list) Andreas
Vincent Veyron schrieb am 18.04.2012 um 00:09 (+0200):
Le mardi 17 avril 2012 à 20:10 +0200, Michael Ludwig a écrit :
Vincent Veyron schrieb am 16.04.2012 um 22:21 (+0200):
I am doing this now, but passing parameters to the query becomes
cumbersome :-(
Le mercredi 18 avril 2012 à 00:30 +0200, Michael Ludwig a écrit :
Vincent Veyron schrieb am 18.04.2012 um 00:09 (+0200):
Maybe people can come up with more helpful
suggestions if you post a concrete example of what is cumbersome.
Sure, the app in my sig has a demo a account which you can
Have your webservice connect to the db as an unprivileged user that has only
select privileges.
-Original Message-
From: Vincent Veyron [mailto:vv.li...@wanadoo.fr]
Sent: April-16-12 8:55 AM
To: modperl@perl.apache.org
Subject: Safe handling of an SQL query
Hi Group,
I maintain
On 16.4.2012 15:55, Vincent Veyron wrote:
My question is :
Can I make sure that whatever query is sent to the server, it will only
be a SELECT... and _never_ a UPDATE or INSERT or DELETE
?
In addition to already mentioned approaches you could also have a look
at the ReadOnly attribute
handling of an SQL query
Hi Group,
I maintain a business application that uses a LAMP stack of Linux +
Apache2 + Mod_perl + Postgresql. One recurring problem I have is that
each client wants his own set of custom reports using queries from the
database.
This is currently covered via a table
On 16 April 2012 18:06, Vincent Veyron vv.li...@wanadoo.fr wrote:
b) You should always keep the control over the selects which are
fired against your db. Otherwise someone can bring down the db
very easy.
You might want to look into setting up a slow query killer. Then you
dont have to worry
Le lundi 16 avril 2012 à 10:45 -0700, Bruce Johnson a écrit :
I'm going to suggest going another direction...what you (and they) want are a
BI system. You can present a set of reports and the system provides for their
ability to do ad hoc reporting and such like.
16 matches
Mail list logo