Getting the logged in user Id via an app proxy

[howmanyaccounts]

Dearest shopify forum users,

I am trying to get the id of the currently logged in user via an app proxy. After perusing almost all of the documentation I have not found a method to do so. Does anybody have any experience of doing so or know of a way? I know that I can create links in the shop and send the user Id with the request but this is grossly insecure. All I see in the request is something akin to:

GET /snip?path_prefix=/apps/snip&signature=snip&timestamp=1379417760&shop=snip.myshopify.com
 0 bytes
10s ago  
From 86.160.19.233, 172.16.1.193, 172.16.0.10, 204.93.213.120

FORM/POST PARAMETERS

None

QUERYSTRING

path_prefix: /apps/endpoint
shop: snip.myshopify.com
signature:snip
timestamp: 1379417760

HEADERS

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1631.0 Safari/537.36
X-Forwarded-Host: snip
X-Queue-Start: t=1379417760.691000
X-Upstream: haproxy02.chi.shopify.com
Accept-Language: en-US,en;q=0.8
Host: snip.myshopify.com
Accept-Encoding: gzip,deflate,sdch
Client-Ip: 86.160.19.233
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
X-Request-Id: 557b68c902293cc884d6f9a330365e31
Connection: close

Any ideas would be superb. This must be possible, if the only method of doing so is to send the Id in the request I will be shocked (gasp)!

Thanks

Chris

[Adam_Harrison2]

Why are you trying to get the customer id, exactly? As far as I know, there's no way for the app proxy to receive any of the customer's information directly (the proxy even strips all cookies to and from your app, so you can't even tell whether a customer's logged in or not). It can, however, render that information using liquid; if your response header is 'application/liquid', Shopify will render the information for you.

Also, keep in mind that you probably shouldn't be using just the user id to authenticate the user, if that's what you have in mind. Identify yes, authenticate, not so much.

Adam

[HunkyBill]

You can use the Proxy to populate the Liquid phase of your rendering needs, and then use a Javascript callback with the customer info to further refine the page rendering. That is one pattern that works in this case.

[howmanyaccounts]

I require the customer Id so I can store information related to the user on my side and conversely render content related to that user in a template back to the client. Using {{ customer.id }} will not help as this is only displayed to the client.

I this case, a gift registry, the user can add a product to what is essentially a cart (but is in fact a wishlist). As there is no facility to store custom lists in shopify I store these lists remotely accessing them via an app proxy. The app proxy accepts posted information (user Id...) and I can successfully add items to the lists. The issue being when I want to render the user's list back I must know again who this user is. I must then create a link http://example.myshopify.com/apps/registry/view/{customer.id}, which is far from perfect. not only because I must include the user Id but because the vendor can alter the url to the app proxy making it difficult to provide the correct url in any liquid templates returned.

I don't know how I could use an Id to authenticate a user but I can trust the response from shopify because I can test the signature provided in the request against my secret. 

It seems the only way of getting the currently logged in user is via get which I do not like. It makes it harder for a shop vendor to integrate an app as they must fiddle with their templates also exposing the user Ids.

[HunkyBill]

I built an App like yours and had no trouble making a customer specific wishlist that included a comments section that only allowed invited customer friends to participate. In other words, each customer's Wishlist was unique to them, included their friends, and the shop merchant had access too. Additionally, this App created collections just for the customer. Liquid and Javascript together were suitable and I had no URL mangling issues like you. It can be done.

[Adam_Harrison2]

Well, uh, in my gift registry app which is about to be released, we solved this problem by using an OAuth authentication scheme with user sessions, based off a shared secret and the customer's email.

[howmanyaccounts]

@hunkybill, mind sharing how you did that? Did you just create a custom collection and append products to it?

@Adam, are you saying that you found the same short comings as me and had to implement some custom solution to get around the issue? (pretty sure I've spoken to you before about this similar app).

[Adam_Harrison2]

We may have spoken, I can't recall. That being said; yes, pretty much. The app proxy wasn't designed to let you authenticate users, only shops, so you need to do it yourself.

Adam

[HunkyBill]

Indeed. I leverage built-in Shopify features as much as possible, in this case collections.

[howmanyaccounts]

I wasn't that bothered about authenticating, it's a wishlist after all, I guess you could add dildos to somebodies list or something but that's about the worst you could do with it, maybe I'm just lacking imagination. Anyway, I digress, the easiest way would be to accept the Id in the request and do a check to see if that user existed in the shop. I wasn't aware you could do any kind of hashing within shopify as you suggest combining the customer's email and the shared secret. 

In my case accepting the id in the get is just going to have to do. 

[howmanyaccounts]

@hunkybill, do you think I'm over engineering this sucker. To be honest I'm only doing a favour for a friend, it's consuming a lot more time than I had expected. I had written a full liquid app using customer collections but I junked it fearing it would scale poorly.

Do you just build an Id for a wishlist out of the customer Id ala 'wishlist-{{customer.id}}' and that is your collection, push objects onto that and then render the wishlist based on that collection?

[HunkyBill]

Pretty much yes. And that little ditty indeed consumed a lot more time, effort and resources than I imagined.

[howmanyaccounts]

lol, maybe I'll throw this away and have another stab. It's taken forever to just figure out how it all works. The docs seem wired towards ruby and that is it, nothing describes very well the workings under the hood. I had to reverse engineer a lot just to get it to work at all. 

[HunkyBill]

Ruby has nothing to do with it. What, you think using C# or Java would help you out? 

Spam.spam.spam.spam.spam.id

The beauty of API based computing is you can use any scripting language you want. I think people are lucky the docs favour Ruby. At least the correct constructs to use read well from that code (in english anyway). Try teaching someone to understand anything with Objective-C, PHP, Java or C# and you have a real mess on your hands as that code reads like junkie on a bender hallucinating bad poetry in the middle of a Swans concert. 

[howmanyaccounts]

I was talking more about how the examples and documentation tell you how to use the rails app builder but do not tell you how things actually work. A lot of it has to be worked out for yourself. I have had no need to use the api yet, that would be the easy part. Just authenticating an app install took a while, the endpoints for authentication are not listed anywhere other than on this forum or various other places. The rails app does all the work for the ruby dev so you have to dig these values out for your self if you want to use a different architecture.

[HunkyBill]

oAuth is well documented. It's a mess no matter what language you choose to learn it with. It's not like Shopify is the only source of frustration for this. Same frustrations apply to all platforms.

[howmanyaccounts]

True enough.

[rickydazla]

I love wishlists!