Dine kommentarer

Thanks. That would be great!
I am doing that. I was hoping to be able to get to the page source of the returned html.
OK...just to make sure it is available for everyone else


<assign property="httpheader:parseHeader.X-Parse-Session-Token" value="[var:signin-SessionToken]" />


All you have to do to make this work for your session tag with parse.com is to
1) Replace my value of "parseHeader" with the name of your wire httpheader tag
2) Replace my value of "var:signin-SessionToken" with the name of your wire variable containing the session token returned from the parse.com login call

All your subsequent calls to wire REST apis will have access to the user that is logged in which means you can reference "request.user" in your parse.com cloud code
Thanks, but it didn't work. I am in the process of creating a simplified version of the scenario. I will share that with you.
More info

I setup a specific test to find out where the breaking point is in the process of assigning the X-Parse-Session-Token.

1) logged in via a terminal and curl to Parse.com to get a session token.
2) took the returned session token and hard-coded it in the httpheader in my wire
3) called a REST api in parse.com, from my wire, and it worked
4) removed the value of the session token from the httpheader and put it in the assign tag, to set the header value, just before setting the source tag of the datasource
5) called a REST api in parse.com and it failed :(

Since it worked with a hard-coded session token in the httpheader tag itself, but not when I did the assign tag (as shown in my prior comments) with a hard-coded value of the session token...

I think I still need your help, please :)

Steve
I don't think I have things working correctly. When I try to retrieve the user on the parse.com side, it gives me a null object. I am assuming that the session token is not getting passed through, but I am not sure.

I have added the following "assign" ahead of each of my "assigns" for the source property of the datasource to parse.com that requires a user to have been authenticated.

I have "alerted" the value of the session token after login to make sure I have a token to assign, and I do.

I have tried to "alert" the value of [httpheader:parseSetQueueing.X-Parse-Session-Token] to see if the "assign" has worked, but I can't get that to work. I don't know if it is supposed to.

Also, I have tried adding X-Parse-Session-Token="" and I have tried not having it in the header initially and assuming it will get added/assigned when I use the assign tag. Neither of them made a difference.

One of my "assign" tags:

<assign property="httpheader:parseSetQueueing.X-Parse-Session-Token" value="[var:signin-SessionToken]" />


Any thoughts?

P.S. I am heading over to the Parse.com side to see if I can figure out how to display the http header info being passed in to their system
Excellent! Thanks for the quick response!
Thanks for the persistence and finding a solution! The use of "superwire" in the main.wire action, called from the subwire did the trick!

It looks like I have a z-order issue with my main navigation menu that wasn't there before, but that should be easy to work through. Everything else is workin great.

I am excited to be able to modularize the distinct portions of code into subwires!
Excellent! I will give that a try.

Also, my prior response was added to the post before I saw this reply, just in case it seems like I wasn't paying attention to your "superwire" option...I wasn't :) I hadn't seen it yet.
Thanks for the response!

As an FYI...My testing shows that any code in the action called by the subwire, except for the unload and the alpha actions, leads to a crash.

The crash happened even without a play tag in the subwire callback action.

Sharing just in case the additional info helps with the outstanding ticket.


Kundesupport af UserEcho