SPServices: SPRedirectWithID in Anonymous Mode – Nope, Won’t Work

I got a question about the SPServices function SPRedirectWithID via email yesterday, and it seemed like it would be good to answer it in a blog post. The idea behind SPRedirectWithID is to allow you to redirect the user to some other page from a NewForm, with the new item’s ID on the Query String.

I’ve been able to implement your $().SPServices.SPRedirectWithID script very successfully. As long as I’m a signed-in user, it works beautifully, redirecting me to a custom display page I put together. Unfortunately I can’t get it to work for an anonymous user. I have given anonymous users access to the list that creates the new item, and have given them permission to add an item. The customized NewForm.aspx loads fine, but once it is submitted, I get the following error: “The data source control failed to execute the insert command”. The funny thing is the new item is created in the target list, but the redirect will not work. I had a workflow attached to the whole procedure, so I tried the whole thing with a new list. This time it just hung on the script, and wouldn’t do anything, yet still it did create the new item. But once I log in as with my Sharepoint credentials, everything works fine. Is it just that these type of list transactions are impossible for anonymous user?
Thanks in advance for any insights you might have.

Nope, SPRedirectWithID won’t work in anonymous mode. It can’t because of the way I’ve had to build it to deal with the commit mechanisms for SharePoint lists. In fact, this was one of the hardest functions to get running in SPServices because of those mechanisms. (As of this writing, it’s stopped working with Firefox, and I have yet to figure out why.)

Here’s the way SPRedirectWithID works, from the documentation. Assuming your NewForm is called NewFormCustom.aspx and the redirectUrl is set to EditForm.aspx, like this:

$().SPServices.SPRedirectWithID({
  redirectUrl: "EditForm.aspx"
});

• On the initial load of NewFormCustom.aspx, the form action is changed to point back to the same page, with ?Source=NewFormCust.aspx?ID=[the last ID created by the current user]%26RealSource=[the actual Source for the page]. The [the last ID created by the current user] is determined by calling the $().SPServices.SPGetLastItemId function.
• When the form reloads, because the ID is present on the Query String, the function then waits until [the last ID created by the current user] is not equal to the value on the Query String. This ensures that the commit has completed. The [the last ID created by the current user] is again determined by calling the $().SPServices.SPGetLastItemId function.
• The user should then be redirected to EditForm.aspx?ID=[the last ID created by the current user]

The tricky part there is the [the last ID created by the current user] part. If we’re in anonymous mode, there is no current user; they are anonymous. If multiple people are submitting items, then we don’t know which one belongs to each person. So the way I’ve built the function (to be reliable) it won’t work in anonymous mode.

All that said, if you feel like you need something similar to work in anonymous mode (and can live without Firefox and possibly other browser support), then you could simplify the function to work for yourself. just be careful!

Bonus bit: I also got this comment on the documentation page for SPRedirectWithID this week:

I’ve got a list with a custom new item form, and it turns out that the SPRedirectWithID function will not work if there is not already a redirect statement applied to the ‘save’ button. The function works perfectly with a standard form, but it will fail if the “save” button only performs a commit – it must also have a redirect action applied. I dont’ know if I just missed this in your setup, but it might be important for those of us who are using custom forms.

True, dat. If the page isn’t going to redirect on submit, then this function won’t work because, as I’ve outlined above, it piggybacks on the existing redirect.