<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Adding connection strings to globals avoids the question of, "where are they stored and where do they come from?" If the user is "configuring a database connection" for ad hoc queries, do you think the security team would consider it a vulnerability to be storing these connection strings with variable_set, or some other created table? I haven't really heard a "that's crazy,man" response yet... so maybe this is not a concern. After all, we do store password hashes in the DB right? Oath tokens, etc. ? <div><br></div><div>FYI: When I use forena, I'll be sure and create users that have read only access to the database. That way you can create data sources that use the power of posgtres and oracles XML generating functions, and seems more secure. I like the idea of white listing SELECT statements, but I don't think that you could really write one that is purely, and I think I might just always wrap the ad-hoc querys in SELECT * FROM ( ad hoc query here ) . Make sure there are no comment characters and I think I'm good to go?</div><div><br></div><div>Regarding Views: </div><div>Views is great! I love and use this module all the time. It does not however pretend to really provide ad hoc query mechanisms, nor an ad hoc reporting system, nor does it provide a database centric reporting engine, and the development of the api is far too much overhead for my purposes. With my prior XML reporting systems you can go from the SQL to a presentable report in less that 5 minutes. I simply cannot match that pace with views. Views 2 doesn't provide an api that will let you select from say a table of moodle users or the financial transactions of a company or any other non-drupal content without significant non-sql code development, and certainly not in 5minutes or less. </div><div><br></div><div>With forena you'll be able to make form letters, etc. and use a wysiwyg editor to design custom report stuff. All you need to know is HTML, plus some custom report tags. </div><div><br></div><div>Really, I'm not trying to compete with the views developers here. You guys ROCK for sure!</div><div><div><div>On Jul 15, 2010, at 10:34 PM, Ronald Ashri wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
2. The connection string (with passwords). Right now I have the site admins hack in connection strings for external databases into settings.php in the sites folder. That probably won't work for a true ad hoc reporting solution, since we may want users to be able to connect to databases from the UI? Is it untenable to store these using variable_set? Are there any ideas for securing them inside the drupal DB?<br>
</blockquote><div><br></div><div>I can confirm that you can connect to dbs by dynamically adding connection strings stored in the DB to <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13.3333px; border-collapse: collapse; ">$GLOBAL['db_url'] </span>at any time, which does save having people editing settings.php</div>
<div><br></div><div>We do it to connect to other Drupal databases for queries.</div><div><br></div><div>For external DBs might be interesting to see if you could use Data (<a href="http://drupal.org/project/data">drupal.org/project/data</a>) to integrate with Views and let users build the queries via the Views UI. Never tried dynamically doing that but I think it is worth considering.</div>
<div><br></div><div>Best,</div><div><br></div><div>Ronald</div><div>---</div><div><a href="http://www.istos.it/">http://www.istos.it</a></div></div>
</blockquote></div><br></div></body></html>