AJAX & Drupal: Post/Response Times

Events happening in the community are now at Drupal community events on www.drupal.org.
jmmec's picture

Hi,

I posted a message over at the Drupal Forum's asking about excessive post/reply times that I see on Drupal 5 using AJAX. With a simple change to bootstrap only the Drupal database, my AJAX post/response times decreased from 900-1000ms to 94-120ms per AJAX query. Instead of copying my post here, the link is below:

http://drupal.org/node/233608

I have a few questions at the bottom of my post and maybe some of the guru's in this group can shed some light in case there are alternative solutions for Drupal 5?

I've done some googling and will do more in case my questions are already answered and I have missed the answers.

Regards,
J

Comments

Your approach is solid. This

moshe weitzman's picture

Your approach is solid. This 'separate script' technique is currently the best way to do stuff without a full bootstrap. Your script won't know who the user is, and thus what his permissions are and so on. You won't get fully rendered node body nor valid user profile info. If you don't care about any of that, then keep doing that you are doing. If you are retrieving sensitive data, then you have to do a whole lot more processing which is where the other 900ms comes in.

We are planning to refactor the bootstrap for D7 after the registry patch lands.

Thanks for the

jmmec's picture

Thanks for the confirmation!!

Yeah, I now understand about some missing "features" such as knowing who the user is, etc. Since it is a private website with not very savvy computer users, I decided to send the UID in the javascript I send to the client, and then have the AJAX messages send the UID back to the server. Not secure, but good enough for my purposes given the type of website.

Regards

careful - sechole waiting to happen

greggles's picture

Since the user can edit the javascript sending the uid this is a security hole waiting to happen. Your user can send UID=1 in their request and then, assuming you use that to determine permissions, they run with full permissions. Yikes!

It sounds like you already know this and are protecting against it, but I wanted to state it clearly so that others don't assume this is a best practice.

--
Open Prediction Markets | Drupal Dashboard

Won't that only be a problem

xano's picture

Won't that only be a problem with register_globals enabled?

don't think so

greggles's picture

In jmmec's own words...

I decided to send the UID in the javascript I send to the client, and then have the AJAX messages send the UID back to the server. Not secure, but good enough for my purposes given the type of website.

As jmmec says, they are trusting the UID that is being sent back by the javascript to be the right UID. If you do the partial bootstrap and don't bootstrap to the point of the session/user being validated then you have to use a trick like this in order to figure out the UID. So, if you are using this code to, for example, determine permissions to see a piece of content or delete something or edit something then that is a security hole.

I stated it more specifically as the focus of my comment so that it wasn't buried as the last sentence of the comment.

--
Open Prediction Markets | Drupal Dashboard

Yeah! I understand the

jmmec's picture

Yeah!

I understand the possible risks, but it is a closed website, and the membership is not capable to try try (or even want) to do damage. Anyway, the AJAX/JS is access is very mundane stuff and it's not like they are going to control the website or rule the world. :)

Regards

Javascript

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: