Question about AutoCompleteField widget

Em Terça 25 Abril 2006 11:10, Roger Demetrescu escreveu:
> Hi all...
>
> Is there any special reason for having a DIV with a
NAME attribute in
> AutoCompleteField ?

Is it a problem somehow?

-- 
Jorge Godoy      <jgodoygmail.com>


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "TurboGears Trunk" group.
To post to this group, send email to turbogears-trunkgooglegroups.com
To unsubscribe from this group, send email to
turbogears-trunk-unsubscribegooglegroups.com
For more options, visit this group at http:
//groups.google.com/group/turbogears-trunk
-~----------~----~----~----~------~----~------~--~---

Hi,

As you all know many hosting providers only permit access
through the database 
server from the web server, not from the outside.

I'm currently on a professional project where such remote
database access is 
needed. There is a simple solution : encapsulating SQL
queries into HTTP requests.

There's a project out there named "PHP Tunnel"
that does that :
http:
//www.mysqlfront.de/manual/fphptunnel.html

But wouldn't it be great if that was handled as part of the
abstraction that 
MDB2 offers ?

One would call $mdb2->query() as usual and that could run
on a local or 
remote-over-http server....

This would simply require to write a new MDB2 driver, and a
little server-side 
script to perform the real database queries.

The only critical part I see is at the
authentication/security level.

Or have I missed something ? Is this already possible ?

What about DB ?

Greetings,

--
   Olivier Guilyardi

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Olivier Guilyardi wrote:
> Hi,
> 
> As you all know many hosting providers only permit
access through the
> database server from the web server, not from the
outside.
> 
> I'm currently on a professional project where such
remote database
> access is needed. There is a simple solution :
encapsulating SQL queries
> into HTTP requests.
> 
> There's a project out there named "PHP
Tunnel" that does that :
> http:
//www.mysqlfront.de/manual/fphptunnel.html
> 
> But wouldn't it be great if that was handled as part
of the abstraction
> that MDB2 offers ?
> 
> One would call $mdb2->query() as usual and that
could run on a local or
> remote-over-http server....
> 
> This would simply require to write a new MDB2 driver,
and a little
> server-side script to perform the real database
queries.
> 
> The only critical part I see is at the
authentication/security level.
> 
> Or have I missed something ? Is this already possible ?

I think the authentication/security level is pretty darn
critical.  In
addition, I don't think you'll find it is either more
flexible or faster
to send the entire SQL query over HTTP.  Far better is
define a web
service that accepts data, and then does the necessary
database access
internally.

Passing arbitrary SQL over HTTP is a recipe for complete and
total
disaster.  You'll be giving everyone the same access to the
database
that the local user has, which probably includes the ability
to do nice
things like "DELETE FROM tablename."  A web
service can make this simply
impossible to do, and is far more truly flexible.  You may
think your
only problem is security, but in truth, you will have to
find a way to
debug SQL remotely, and will only encourage disorganized
spaghetti code.

Your only decision is what kind of web service to set up. 
XML-RPC and
SOAP are pretty similar in that they allow you to do this
kind of thing:

$remote->saveAdminData($user, $pass, $whatever);

and the code is sent to the server and then executed.

REST is looser, and only requires that every resource has a
unique URI.
 In your case, I think REST may be a better choice, because
you're
clearly looking for flexibility of access to the data in
terms of querying.

Depending on what information needs to be retrieved, instead
of defining
a single url that you query for data (http://www.example.
com/xmlrpc.php,
for instance) you will instead do a similar process to
database design.
 Say you want to retrieve a widget by ID, you might have
widgets at:

http://www.ex
ample.com/widgets.php/id/5
http://www.ex
ample.com/widgets.php/id/6

Read-only access to widgets would go through widgets.php. 
The data can
be returned as XML, text, serialized PHP, whatever.  All you
need is a
Content-type header.  To modify data, you would provide a
separate
interface, such as:

http://www.exam
ple.com/savewidget.php

data would be sent via POST like a normal web form. 
Response from
savewidget.php could simply tell you where to access the new
data,
perhaps using an XML file like so (anything is possible,
this is a
rather brainless example):

<result>
 <success/>
 <widgeturl>http://www.example.com/widgets.php/id/7</widgeturl&g
t;
</result>

The strength of this approach is that you distribute your
web
application across multiple requests, allowing (for
instance) moving
resources to separate servers should scalability become an
issue.  You
also are not locked into a single API, and can upgrade the
server
without affecting older installations.

Also, security is handled via simple mechanisms: SSL and
HTTP Auth.
This removes the need to tunnel altogether.  Debugging works
on several
fronts, as you will have the HTTP access log to track access
to widgets
as well as other sources.

In any case, sending raw SQL over HTTP is just about the
worst idea ever
 -
particularly because the issues with doing so will not
become
apparent until you have deployed the entire application and
have to
rewrite it from scratch.  Not fun.

Remote data access is the primary reason web services were
devised in
the first place, so I would recommend scouring Google's
archives for
examples of usage of REST (Representative State Transfer,
not
Restructured Text), XML-RPC and SOAP, and decide which is
best for your
situation.

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi Greg,

Greg Beaver wrote:
> Olivier Guilyardi wrote:
> 
>>I'm currently on a professional project where such
remote database
>>access is needed. There is a simple solution :
encapsulating SQL queries
>>into HTTP requests.
>>
>>But wouldn't it be great if that was handled as
part of the abstraction
>>that MDB2 offers ?
> 
> I think the authentication/security level is pretty
darn critical.  In
> addition, I don't think you'll find it is either more
flexible or faster
> to send the entire SQL query over HTTP.  Far better is
define a web
> service that accepts data, and then does the necessary
database access
> internally.
> 
> Passing arbitrary SQL over HTTP is a recipe for
complete and total
> disaster.  You'll be giving everyone the same access
to the database
> that the local user has, which probably includes the
ability to do nice
> things like "DELETE FROM tablename."  A web
service can make this simply
> impossible to do, and is far more truly flexible.  You
may think your
> only problem is security, but in truth, you will have
to find a way to
> debug SQL remotely, and will only encourage
disorganized spaghetti code.

About security: I do not follow you. If the tunnel is secure
I don't see where 
the problem is. As an example, what about the thousands of
people using SSH to 
administer remote servers ? They're root, they can rm the
whole filesystem, but 
SSH makes it safe. MDB2 could implement an "internal
HTTP tunnel" that handles 
such security transparently.

In this situation, I don't see how debugging SQL would
differ from using MDB2 as 
one currently do.

If I understand correctly you propose to make a webservice
that's specifically 
designed for my needs, and, as such, tries to reduce
security risks as much as 
possible.

> Your only decision is what kind of web service to set
up.  XML-RPC and
> SOAP are pretty similar in that they allow you to do
this kind of thing:

I agree that putting SQL queries into higher level methods 
(getWidgets(), 
addWidget(), etc...) that run on the server, and making
these available through 
XML_RPC or SOAP sounds good. It may be even a good way to
separate, say, the 
Controller from the Model layer, but that's another
question.

However, a webservice and a SQL tunnel are two different
approaches, and I don't 
see why one is so obviously better than the other to you.
It's a design choice, 
and depends on the context.

> REST is looser, and only requires that every resource
has a unique URI.
>  In your case, I think REST may be a better choice,
because you're
> clearly looking for flexibility of access to the data
in terms of querying.

REST looks great. But you are discussing the details of the
webservice 
implementation while I'm simply not convinced a webservice
is better than a tunnel.

> Depending on what information needs to be retrieved,
instead of defining
> a single url that you query for data (http://www.example.
com/xmlrpc.php,
> for instance) you will instead do a similar process to
database design.
>  Say you want to retrieve a widget by ID, you might
have widgets at:
> 
> http://www.ex
ample.com/widgets.php/id/5
> http://www.ex
ample.com/widgets.php/id/6
> 
> Read-only access to widgets would go through
widgets.php.  The data can
> be returned as XML, text, serialized PHP, whatever. 
All you need is a
> Content-type header.  To modify data, you would provide
a separate
> interface, such as:
> 
> http://www.exam
ple.com/savewidget.php
> 
> data would be sent via POST like a normal web form. 
Response from
> savewidget.php could simply tell you where to access
the new data,
> perhaps using an XML file like so (anything is
possible, this is a
> rather brainless example):
> 
> <result>
>  <success/>
>  <widgeturl>http://www.example.com/widgets.php/id/7</widgeturl&g
t;
> </result>
> 
> The strength of this approach is that you distribute
your web
> application across multiple requests, allowing (for
instance) moving
> resources to separate servers should scalability become
an issue.  You
> also are not locked into a single API, and can upgrade
the server
> without affecting older installations.

This is a lot of interfaces specifications where my only
need is to access a 
remote server.

I somehow see your point with load balancing, and must admit
I did not think 
about how this is feasible with tunnelling.

> Also, security is handled via simple mechanisms: SSL
and HTTP Auth.
> This removes the need to tunnel altogether.  Debugging
works on several
> fronts, as you will have the HTTP access log to track
access to widgets
> as well as other sources.

Maybe that "tunnel" is not the right word. A
diagram (see below) should help 
clarifying. I think that what I call tunnel actually is a
web service that 
allows to send arbitrary SQL queries... That's a little
confusing, but still 
coherent I think.

> In any case, sending raw SQL over HTTP is just about
the worst idea ever
> 
- particularly because the issues with doing so will not
become
> apparent until you have deployed the entire application
and have to
> rewrite it from scratch.  Not fun.

That's very affirmative. It depends how it's done IMO.

> Remote data access is the primary reason web services
were devised in
> the first place, so I would recommend scouring
Google's archives for
> examples of usage of REST (Representative State
Transfer, not
> Restructured Text), XML-RPC and SOAP, and decide which
is best for your
> situation.

I don't agree. "Remote data access" is a very
generic term.

How can you, for example, compare :
1 - a developer like me who is the only one to have control
on both the client 
and server side.
2 - public/commercial web services provided by UPS, Amazon,
Ebay, and the like, 
where the client side is totally out of control

?

These are both "remote data access", but under
very different circumstances...

Now, let me go into the details of my prefered solution :

                       +-------------+
                       | Application |
                       +------+------+
                              |
       
+---------------------|------------------------------------+
        | MDB2                |                             
      |
        |             +-------+----+   
+------------------------+ |
        |             | Public API +----+
MDB2_Driver_HTTPTunnel | |
        |             +------------+   
+---------+--------------+ |
        |                                         |         
      |
       
+-----------------------------------------|----------------+
                                                  |
                                            +-----+-----+
                                            | SOAP_WSDL |
                                            +-----+-----+
                                                  |
                                                HTTPS
                                                  |
                                         
+-------+-------------+
                              +-----------+
Services_WebService |
                              |          
+---------------------+
                              |
       
+---------------------|------------------------------------+
        | MDB2                |                             
      |
        |             +-------+----+    +---------------+   
      |
        |             | Public API +----+ MDB2_Driver_* |   
      |
        |             +------------+    +----------+----+   
      |
        |                                          |        
      |
       
+------------------------------------------|---------------+
                                                   |
                                         
+--------+--------+
                                          |    Database    
|
                                         
+-----------------+


Benefit : just use MDB2 as usual, only the dsn changes...

--
   og

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Olivier Guilyardi wrote:
> Hi Greg,
> Greg Beaver wrote:
>> I think the authentication/security level is pretty
darn critical.  In
>> addition, I don't think you'll find it is either
more flexible or faster
>> to send the entire SQL query over HTTP.  Far better
is define a web
>> service that accepts data, and then does the
necessary database access
>> internally.
>>
>> Passing arbitrary SQL over HTTP is a recipe for
complete and total
>> disaster.  You'll be giving everyone the same
access to the database
>> that the local user has, which probably includes
the ability to do nice
>> things like "DELETE FROM tablename."  A
web service can make this simply
>> impossible to do, and is far more truly flexible. 
You may think your
>> only problem is security, but in truth, you will
have to find a way to
>> debug SQL remotely, and will only encourage
disorganized spaghetti code.
> 
> About security: I do not follow you. If the tunnel is
secure I don't see
> where the problem is. As an example, what about the
thousands of people
> using SSH to administer remote servers ? They're root,
they can rm the
> whole filesystem, but SSH makes it safe. MDB2 could
implement an
> "internal HTTP tunnel" that handles such
security transparently.
> 
> In this situation, I don't see how debugging SQL would
differ from using
> MDB2 as one currently do.
> 
>> Also, security is handled via simple mechanisms:
SSL and HTTP Auth.
>> This removes the need to tunnel altogether. 
Debugging works on several
>> fronts, as you will have the HTTP access log to
track access to widgets
>> as well as other sources.
> 
> Maybe that "tunnel" is not the right word.
A diagram (see below) should
> help clarifying. I think that what I call tunnel
actually is a web
> service that allows to send arbitrary SQL queries...
That's a little
> confusing, but still coherent I think.

The security problem is that it is probably easier for a
hacker to enter
a web site and make use of the tunnel to run arbitrary
queries, than it
would be to temper with SSH (BTW: you should never be able
to SSH
directly into the root account, but instead SSH into regular
user
account, then "su")

Anyway, if you have access to the remote db server to
install a script,
why not make that script return the data you want directly.
Yes, this is
less flexible than being able to run any SQL queries, but
security
always comes at a cost.

If you want to go the MDB2-way, you'd have to think about
your queries
as stored procedures (which limits the security problem
aforementioned),
call them as resources of a web service, and wrap the result
into a
MDB2_Result in the client-side driver for MDB2.

So, it would look like you're running SQL queries, but
actually you
would have to do some magic to turn a SQL query into a
webservice call.

Anyway, running arbitrary SQL queries through the HTTP
tunnel is
obviously possible, but doing so is a big security risk and
shouldn't be
used by someone who doesn't know what they're doing (no
offense).

 -Philippe

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php