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.

6 Comments

    • Matt:

      I added an explicit comment to the SPRedirectWithID docs about this. As for the other functions, there are often differences in implementation and permission settings, so it’s not always a yes/no thing; sometimes it’s a little more grey. My hope is that people think a bit about what the function is *doing* so that they can reason it out. You know me and the Socratic method. ;+)

      M.

      Reply
  1. For what it’s worth, if you want to use SPServices to grab the form data and create the item using UpdateListItems, you can then grab the ID of the newly created item out of the response XML with the following code and then just manually redirect the yourself… I do this all the time:

    var newID = $(xData.responseXML).find(“[nodeName=z:row]”).attr(“ows_ID”);

    Reply
    • Absolutely, Mark. The trick with SPRedirectWithID was to come up with a function which would work without any other development and with most SharePoint NewForms. But if you’re comfortable with SPServices and the Web Services, building your own form behavior is going to be more elegant and a better UX.

      M.

      Reply
  2. Any SPServices function that uses the UserProfileService will NOT work in anonymous mode. I recently learned this when one of my existing data view web parts stopped working after enabling anonymous access. Apparently it doesn’t matter whether or not you explicitly try to pass Windows credentials—if anonymous access is enabled on the IIS application, you always get an error back from UserProfileService.asmx. (Using MOSS 2007.)

    Reply
    • Dan:

      Since all of the Web Services run under the current “user”, that doesn’t surprise me. The UserProfile operations wouldn’t really make any sense if your users didn’t have an identity (were anonymous). I hadn’t thought about it prior to your comments, but it does seem to make sense!

      M.

      Reply

Have a thought or opinion?