Thanks for the update! We eagerly await the 1.7 beta!

The linked "brief description" states:

| Never call an action directly by saying:
| ...href="/mod/mymod/actions/myaction.php"
| This circumvents the security systems in Elgg.

Am I right to assume that this won't work at all in 1.7? (If it would work, then anyone could still create such links, even if the site owner of plugin developer would do things the secure way.)

(Sorry if this is posted twice, but the first did not seem to have come through, maybe because I linked to that article? If this is pre-moderated then a warning would be in place?)

@Arjan - Directly linking to an action will still work in 1.7 but it is highly recommend to avoid this practice. As long as the engine isn't loaded in the action file manually, direct linking will not work. In a later version of Elgg directly calling the actions will be prevented by htaccess.

Thank you for the clear information, the documentation makes it easy to follow.

Hi Brett,

I've converted some form actions into AJAX requests for better usability in my Elgg instance, but doing so meant disabling use of the action_gatekeeper() to keep those requests simple (as otherwise i'd need to regenerate the tokens on every request and update the form values - which could result in a race condition as the requests may fall out of sequence).

Is there a recommended method or some guidance for using AJAX requests in Elgg as currently i'm a little in the dark about how re-factor these requests apart from settings them up as views?

Regards
Milan

Milan,

AJAX is something that will need a better solution in the future. Because of the security implications of disabling action tokens, I highly recommend that you re-enable the token check. What you can do is set up an AJAX endpoint that serves up tokens for the current session and use JS to update the tokens in your ajax requests.

Hi Brett,

forcing an application to renew tokens is not very practical as it is very likely to lead to all sorts of race conditions, let alone the additional load on the site.

I understand the need for security but allowing developers to bypass it by allowing an action registration with a flag to say that it is unsafe would be a good interim solution until something more robust (and scalable) is available in the core.

The alternate is that developers not wanting this feature will misuse one of the other handlers ...

Regards,

Sam.

Sam,

What race conditions are you referring to? Tokens aren't sequenced...they are good for an hour. I'm not sure that the additional load from requesting a single token once an hour is anything noteworthy or worrisome, especially when the load from a full page request--which happens much more than once an hour on active sites--is much more.

The security implications of operating without tokens are severe enough that I disagree that having an option in core to turn off tokens is an acceptable solution. Action tokens are not so much a feature as a requirement for a secure sever. Core needs to be secure. If a plugin bypasses actions by implementing its own handler, it must implement its own security.

Brett

Brett,

thanks for the clarification. I wasn't expecting the tokens to be valid for so long, I was expecting something in the region of five minutes to make the use of tokens (more) effective. With something like the widget canvas that could get busy. A token which is valid for an hour certainly reduces the load and makes the migration to using action tokens for everything considerably easier.

I understand that the use of an action token is one of the most effective ways to reduce the chances of CSRF attacks so I just want to make sure that it can consistently work. Is there a reason not to use tokens for all requests?

Cheers,

Sam.

Sam,

> Is there a reason not to use tokens for all requests?

Actions are the only requests that should actually DO anything. I don't see the benefit of using tokens on read-only operations (page handler requests) in a properly written plugin. Some of the confusion is because the documentation is sparse on some basic plugin best practices. I plan to improve the documentation, but there are only so many hours in the day :)

Brett

Hi Bret,

I must be missing something; page handlers do something as well. In general they give the user access to information which may not otherwise be visible. As such opening these up to an attack means that the value of access controls are lessened. Agreed in an attack data can't be changed but it can gain access to information which may be private or shared amongst a select community (not public).

I can understand that we don't want to polute the address (URL) with this information generally thus making the sharing of information difficult (normally done by sending someone a URL) but it seems to me that whilst using tokens for actions does limit the scope of attack to changes it doesn't address this for reading non public information.

I think it is important to know which attack profiles are being addressed.

Cheers,

Sam.

Sam,

The action token is for CSRF attacks, not for managing access to content. That is why page handlers should use calls to isloggedin() or isadminloggedin().

Cash