Nodepal

Please provide the code you'd desire to commit to the drupal.org repository, licensed under GPLv2... before anyone can review it.

And note that contrary to http://groups.drupal.org/node/121404#comment-395514 code does not need to be PHP. We happily host dreditor. And also drush which is not a Drupal module either (although PHP).

Actually, the CVS application is for modules, themes, and installation profiles. I would find difficult check other type of code against the Drupal coding standards. :-)

There's nothing to say a module can't be PHP. We use modules for 'other' things like database drivers, drush, dreditor, etc.

@Dave Reid: The projects you list have not been created from users who applied for a CVS account and used those projects as proposed module for the application.

If we are going to accept every PHP file for an application, then we should be prepared to CVS applications where the proposed "module" is a third-party library (maybe GeShi, or a WordPress plugin, or a JavaScript plugin).
I think this needs to be discussed a little more, before to change what the current CVS application requirements report.

I say, if someone wants to host connect-to-Drupal GPL v2+ code on Drupal.org they are most welcome regardless of the host system.

@chx: You approved a CVS application where the applicant provided a plain text file; it should have been declined just for the fact the text didn't contain any call to Drupal functions. ;-)

(I am joking.)

Anyway, this is not the place to discuss changes to the CVS application requirements.

As per requirements, the motivation message should include more than two sentences (the exact words are a few paragraphs) that describe the project features. For themes, it should include also a screenshot of the theme (at least 640x400 pixels), and (when possible) a link to a working demo site; for modules, it should include also a comparison with the existing solutions.

exports.getField = function(client, nid, fieldName, callback) {
  var field = new Array();
  var fieldColumnName = "field_" + fieldName + "_value";
  client.query(
          'SELECT type FROM node WHERE nid=?',
          [nid],
          (function selectCb(err, results, fields) {
            if (err) {
              throw err;
            }
            for (result in results) {
              field[result] = results[result].type;
              client.query(
                      'SELECT ' + fieldColumnName + ' FROM content_type_' + field[result] + ' WHERE nid=?',

Is this going to allow SQL injection since it's not using placeholders? or escaping field or table names?

If you open MySQL access to site users (via Javascript), they can by definition run any query that MySQL GRANTs access to (either by hacking the Javascript, or just connecting with their favorite desktop MySQL client). Placeholders, type check etc in the JS are meaningless from a security point of view.

This suggests to me that the main question is: what table/column privileges are secure? This would need to be quite restrictive, and I think needs to be extremely explicitly documented with each callback.

This could be used to allow SELECTs of basic node content/fields, however this is on the condition that node_access is not used, and all site content is publicly readable. There is no way to build a node_access compliant system using this approach without adding MySQL views or stored procedures to enforce the node_access JOIN.

@Owen
node.js is a server, not client. users do not have mysql access.

views are created on the server in node.js. It should be up to the developer of the node.js app to check for node_access.

Also, nodepal is an integration layer for developers, it's nothing that site administrators would be exposed to.

This makes a lot more sense in that case - I think it would still need careful attention to security though.

Hi. Please read all the following and the links provided as this is very important information about your CVS Application:

Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for your application. Please read the following documentation on how this affects and benefits you and the application process:
Migrating from CVS Applications to (Git) Full Project Applications

• The status of this application will be put to "postponed" and by following the instructions in the above link, you will be able to reopen it.
• Or if your application has been "needs work" for more than 5 weeks, your application will be marked as "closed (won't fix)". You can still reopen it, by reading the instructions above.

Hi @synodinos. Great that you got that started. So, make sure you read up here as there are explicit instructions: http://drupal.org/node/1075406

Then if you feel you want to continue to Full Project access, then change the Project type of this issue. Please consider and read carefully. The more you refine your module and are familiar with Drupal best practices the quicker the application process can be. But, we still have the same capacity (all volunteer) to review projects, so we cannot promise a quicker review time at this moment.

Please note that I have not actually looked at your project yet, but just speaking general.

updating title

Hi synodinos,

Since you opened this application, a new module has been created: Nod.js integration. At a quick glance, it looks like you're focusing more on the node.js side of the integration, and that module is focusing more on the Drupal side, so this might be a good opportunity for collaboration. Drupal.org heavily favors collaboration over having multiple projects with very similar goals. If collaboration won't work for some reason, please explain why.

I'm setting this to "needs work" awaiting your response. Please set it back to "needs review" when you decide whether you want to keep pursuing a separate project or contribute to the existing project.

Closing due to inactivity, feel free to re-open if this was a mistake.