Problem with session management/cart with swell-js library - desperate for help

[johnrisby]

Hi all,

tl;dr - swell-js site having problems with cart not being cleared when user is logged out and then being associated with the next user to log in on that browser, plus a new problem where logging out causes the carts in the admin section to lose association with the customer completely.

I'm using the swell-js library in our next.js app. I'm utterly lost as to what is going on with session management and really need help. I've asked Swell directly a day ago, and just checked, but there's no reply from the devs yet and I wondered if someone else has had this or knows what is wrong or what I'm doing wrong.

Bottom line is when a user logs out (I call swell.account.logout) and then a new user logs in - both me, on a dev machine but with different swell accounts - the cart from the first user becomes attached to the second user. Not just in the frontend, but in the swell admin order section where you can see carts (active/inactive etc).

Now, I thought I may have a fix for this - although it doesn't quite make sense why - but another problem means I can't test it.

After calling logout, the user object is empty (checked via swell.account.get) - which is correct. But if I call swell.cart.get I still see the cart from the logged out user. So I think the issue is when I log in to a new user, the library is picking that up cart up from the session, and sending it to swell and associating it with the newly logged in user.

In fact, another example from yesterday - if I log the user out so the user object is now empty but the cart object is still valid - and I call swell.cart.setItems([]), it wiped the cart that was associated with that customer in the swell admin backend, even though the user was logged out. Which suggests strongly that the cart object is not being cleared in the session when the account is logged out.

The potential fix - if I manually clear the swell-session cookie after log out, the cart is now emptied. I'm not sure why I'd need to manually clear it as I didn't manually set it, the library did, and I presumed the call to logout would do that? (I have read some things about the X-session token but that appears to be relevant for people working without the swell-js library which should handle it itself).

But... and this is where my problem gets worse. I can't test whether this is the fix or not, because now when I log out a user, the cart in the admin section is no longer associated with that user. It's now got no owner. I'm sure this is new behaviour?

I've got some older carts in there that are associated with other test accounts, but any new cart I create after logging in to a user, which then shows up as being linked to that user, loses the association to the user when I call swell.account.logout ...

I'm sure that didn't happen yesterday - otherwise how would abandoned carts work if they lose their association with the user account when the users logs out? Also, what would be the point in saving a cart with no account, and why would I have some older carts that are associated with users?

Sorry this is long but I'm tearing my hair out here. Maybe I'm doing something wrong, maybe Swell has a bug in the library or the system - frankly at this stage I don't care, I just need it to work and it's gone from one problem to another and this is a completely unexpected delay to our project that is incredibly frustrating!

Thanks for reading and if anyone has any ideas, please do let me know. Thanks.

[johnrisby]

After wasting days waiting for support to get back to me, today I wrote a clean test app to make sure everything was working as I thought and the results are worrying and raises privacy issues, usability issues, and lost sales from a broken abandoned cart feautre.

swell-js api docs say to use account.login and account.logout.

What happens is this:

You call account.login and it sets a session cookie in the browser.

If the customer adds to their cart, it is saved in that session in the browser and it is also sent to the Swell servers. You can see the carts in the admin section under Orders/Carts.

While the user is logged in, you can see that a particular cart in the admin section and who it belongs to. So far, so good. This means you can send abandoned cart emails as well because the Swell database is storing the cart items and the user...

But if you call account.logout, a few things happen - but not, I would wager, what you would expect.

Calls to user functions no longer work, obviously, because the user is logged out, so that's good. But the swell-session cookie that the login call created is not deleted by the logout call...?

The users cart is still in the browser session. And worse than that, any call to a cart function such as setItems([]) - which empties the cart - still works and clears that cart, not only in the browser, but in Swell's database.

But... that's not actually a huge problem for the user, because when you call account.logout, the cart stored in Swell's database - the one you saw earlier in Orders/Carts, and the one used for abandoned carts, is disassociated from the user that created it. It's just sat there, a bunch of item data without an owner. How can you send an abandoned cart email to a cart without an owner?

The only way for that to be re-associated with the user is if they log in again - on the same device, in the same browser. If a user does that, then the Swell database re-associates that user with the cart in their database. But unless they do that, it's just orphaned and useless.

And because of this design, if the user logs in to another device - say their mobile - then the items that they had put in their cart on their other device (say their laptop), are nowhere to be seen. Even though Swell has the data in their database. But because they decided to delete the association with the user, it's meaningless unless the user logs back in on the original device...

Oh, and if your partner or someone else who uses the same device as you then logs in in to their account, guess what happens? Yes, any items you left in your cart - that are saved in the browser session but without a user - are now associated with their account!

And not just in the frontend, but in the Swell database.

That cart that was disassociated from the user when account.logout was called is now owned by someone else. That could cause some awkward discussions at the dinner table or ruin a birthday surprise... The same thing could happen if you use a public computer ie in a library etc (admittedly the chances of someone using the same shop, unless it's a huge one, is slim but it still shouldn't work like this).

The solution, which I discovered after a lot of work testing this and trying to find out what on earth was going on, is to log out by deleting the swell cookie directly. Yes, that same swell cookie that was set by the swell-js login call. The one that the swell-js logout call doesn't delete.

I've been waiting for days for Swell to confirm what is going on and had to push them again and again and even spend time making the test site to show them exactly what is happening and explain why it shouldn't work this way.

Their reply starts "After further review, they can understand your problem with disconnecting the cart from the account. But they won't consider this a bug because other users may expect this kind of logic."

Who? Who would expect this kind of logic? Why would calling logout do something different than the opposite of login? Why would it delete the cart ownership in the Swell database? They then go on to say that my solution to delete the cookie directly is the best way to do it but to also call the logout function after that "This step is an optional since it won't do anything currently with empty session, but I recommend keeping it if we would make some improvements in the future."

Which I read as "in case we ever fix our API library" because it makes no sense to call a logout function after the session cookie has been deleted.

All the logout function needs to do is what it should do and what you'd expect it to do - delete the damn session data - and logout. And not delete any data in the Swell database. That's it. That's what I'll be doing manually now by deleting the cookie. But that's how the function should work.

I'm absolutely furious about this. Not only have I lost days of development time trying to work out what "I'm" doing wrong, when actually I'm doing nothing wrong at all. I was doing what their documentation says. The fact is their library works (or doesn't work) in a way that makes no sense. Shops using their documented way of logging out are not only causing their users to lose the ability to continue their order on another device, and not only risking a breach of data (technically unidentifiable but if it's just you and your husband/wife etc then ...), but it also means shops have abandoned carts sat in their system that they can never do anything about.

I've really spent all week thinking I must be going mad or making a huge mistake, but today it was confirmed this is how the swell-js API works and Swell say it's not considered a bug...

Not only has this been a week where I've lost so much time to this bad design/bad documentation/whatever you want to call it, but not even an apology - just a "not a bug as someone might expect it to work this way"... Really Swell?

I'm also frustrated I've now spent a further 25 minutes writing this explanation but I don't want anyone wasting their time trying to answer my question, and hopefully it may help some other people. It's now gone 2pm on Friday afternoon and I'm going to be working all weekend but I'm still not going to make up for the lost time this has caused.

As soon as our project goes live - because it's too late to walk away from Swell right now without further financial damage - the project to move to another system starts. What a waste of time.

[coderreco]

After reading this I felt inclined to have a go and see if I could create a solution. I believe I did, let me know if it would work for you.

I can see why you're frustrated but...I don't necessarily agree that this default behaviour from Swell is wrong. I'm going to defend Swell here, but I can see how it is wrong for your use case. Hear me out!

I can think of scenarios where both options are preferred(either maintaining cart session after logging out or clearing cart session after logging out). Example: As I freelancer there are some websites where I will have accounts for both personal use and business use. I also have a credit card for personal use and for business use. Say I am logged into my business profile and browsing a store, see something I want and add it to my cart. I'm preparing to checkout and conclude that this is more of a personal expense and therefore shouldn't use my business account. In this scenario being able to logout, disassociate that cart from the business account, login to personal account and automatically connect to that cart session is a much more seamless experience. The context of the store and the desired behaviour makes a difference here.

I agree, their documentation leaves a lot to be desired. Would love some better docs, Swell. And throughout the project I am currently working on(my first using Swell) I've been left scratching my head from time to time, but I think I am beginning to better understand the design philosophy of their API and product.

I think their should be better session management, or at a bare minimum better docs explaining how it works.
In a perfect world I think their swell.account.logout() could have some optional parameters, like swell.account.logout(saveCartToAcc, clearSession).

I am not sure you are aware of this or not but you can update a cart with the email from an account, and it will associate that cart with that customer in the database without having a logged in user in the session. For example swell.cart.update({account: {email: email}}) will associate the cart with any account in your database that has that email address. account_id: {{accountId}} will be added to the cart object, and it will also populate the account object in your cart with any details from the account.

So we can make our own logout function that handles what you need.

const logoutUser = () => {
   // store account email
   let email = account.email
   // logout swell user
   await swell.account.logout()
   // assign cart to account
   await swell.cart.update({account: {email: email})
   // clear session
   clearSession()
}

That should logout your customer, make sure the cart remains tied to their account, and then remove that cart and its history from the browser session. This could be passed on to the customer as well:

const logoutUser = (saveCartToAcc) => {
   // store account email
   let email = account.email
   // logout swell user
   await swell.account.logout()
   // assign cart to account if customer elects to do so
   if(saveCartToAcc){
      await swell.cart.update({account: {email: email})
   }
   // clear session
   clearSession()
}

I visualize this as being a checkbox in my slide-over cart, or an option within the account preferences I make available to my users.

In terms of recovering accounts or allowing users to pick up a shopping session on another device, consider these options:
After the user logs in a call is made to the backend api:

// get account using frontend api
const account = await swell.account.login(email, password)

// get account data from swell database using backend api
const accountData = await swellnode.get('/accounts/{id}', {
   id: accountId
}

One option is to use expand to expose the carts attached to that account:

// get account data from swell database using backend api
const accountData = await swellnode.get('/accounts/{id}', {
   id: accountId,
   expand: "carts"
}

Expected response:

{
  "first_name": "Dev",
  "last_name": "Account",
  "email_optin": true,
  // more fields
  "carts": {
    "count": 15,
    "page_count": 3,
    "page": 1,
    "results": [...]
   }
// more fields
}

Or you can include to create a nested object with more control:

// get account data from swell database using backend api
const accountData = await swellnode.get('/accounts/{id}', {
   id: accountId,
  "include": {
        "latest_cart": {
            "url": "/carts",
            "params": {
                "account_id": "id"
            },
      }
}

Then you can filter the results further, and sort:

// get account data from swell database using backend api
const accountData = await swellnode.get('/accounts/{id}', {
   id: accountId,
  "include": {
        "latest_cart": {
            "url": "/carts",
            "params": {
                "account_id": "id"
                // any other fields to specify requirements
            },
            "data": {
                "abandoned": true,
                // "expand": ["items.product", "items.variant"], // Uncomment line to expand within the cart
                "sort": "date_last_accessed desc"
            }
        }
    }
}

This worked well for me in postman. Here is a little of what it looks like:

Then if carts are found the customer can be notified and provided the option to continue shopping. I think I am going to implement this with a toast in my project:

if(accountData.latest_cart.results > 0) {
   toast.message('Cart found',{
      description: 'Would you like to continue shopping?',
      duration: 10000,
      action: {
         label: 'Yes',
         onClick: () => await swell.cart.recover(accountData.latest_cart.results[0].id)
      },
   })
}

[ericingram]

Appreciate the detailed walkthrough @coderreco, I'm sure this will be useful for others

This behavior is by design, by default, but as pointed out above there are various ways to make it work as you prefer. Many other platforms do the same by default as well. I would imagine that on a site with mostly repeat-customers (like Amazon) it would be better to stick the cart to the account and not to the session.

Also agree that adding an option to choose one or the other behavior with the API would make a lot of sense

[johnrisby]

What makes sense Eric is properly documenting how this works, which you don't. The documentation even has links in the side panel that don't exist on the page (even on the most basic page of all - https://developers.swell.is/frontend-api/basic-usage#adding-items-to-the-cart). We want a headless ecommerce solution because we're programmers, but that doesn't mean we want to learn how to use it by reading the source code on github or spending days trying to second-guess what you haven't bothered to write down.

There's no explanation in the SDK docs that this is the behaviour. I'm not going to give a lengthy reply (edit - I have, but it could be longer if I address everything) because I'm done with Swell after another wasted week waiting for support to get back to me about this (and given you now say it's "by design", I have no idea then why no one could just say that and why I had to put so much effort into working out what was going on?)

Thank you @coderreco for your reply. I'm glad you agree that the documentation is terrible. I still disagree that this is the right way for it to work, documented or not, though. If there was an option, fine, and as long as it's explained, but as it is it doesn't work as I would expect and there's nothing to explain you have to do something that isn't obvious, or documented, to make it work.

Of course, we can all have our own view of how these things should work, but I don't think a freelancer switching to a work or personal account is more important than preventing the risk of a partner seeing what you've had in your shopping cart if the site designer deleted the cookie manually, or the risk of an implementation of Swell deleting the users carts in the swell database simply by calling "logout" and losing abandoned carts.

Again, the fundamental issue is the complete lack of depth in the documentation and the lack of knowledge in the front-line support (although friendly, especially Jim) for something that is "by design" - and the slowness in getting replies from someone who does know. Even then, having the reply passed back by frontline and then having to reply to them to ask a follow on question to the engineers etc etc ... still, we're not paying enterprise pricing so - as I've been told before - "technical support" is limited... That's fine if you have good documentation, but it's a borderline con when you don't and you expect paying customers to guess how your system works.

I haven't replied yet to @coderreco because I've literally not stopped since catching up all weekend on a week that was ruined by this nonsense. The good news is I've stripped Swell from my site completely and, as I was doing a lot of it myself anyway in PayloadCMS (amazing software), now I've written a cart that works as I want - with proper session management ;) - I'm closer to going live with this site.

Hugely disappointed in Swell though for many reasons (and Eric knows some of them already) but glad I've moved on from this before going live rather than after.

[stafyniaksacha]

I can add that it's impossible to use SSR with the SDK, impossible to handle how cookies are set (we may want to use http only cookies, customize domain, etc...), session check can take seconds (minimum 1s, which is huge in ecommerce), we don't have any view on what is prioritized (because of asana) and contributing seem a pain (I think GitHub repo are not main repo)

[cwierzbicki00]

@johnrisby Currently experiencing a number of my own issues with Swell... Should we stay with Swell? Still have a chance - although it would be moderately painful - to change course before go live.

[stafyniaksacha]

Swell is a good product, I think they should create an offer to be able to run in the edge, but this would require time to ship the feature.

[johnrisby]

I can't tell you what to do, obviously, but I moved away. I was already using PayloadCMS on our site (fantastic software, and open source and free), and I've built my ecommerce software on top of that. Swell is nice in theory but in reality... I'm glad I moved away. If nothing else I don't have to wait days for a reply from support, and there's an (active) Discord server for fast help if needed etc.

[vettloffah]

There are lots of these types of issues with swell, where you think you must be doing something wrong but then... surprise, it's either a bug or it works in a weird way and you end up spending half a day figuring that out instead of actually developing and shipping code. We've slowly but surely had to start custom developing a lot of the ecomm functionality that swell is supposed to handle out of the box. If I had known that, I would have gone with something like shopify plus, or just used an open source solution. At least with open source you can actually see the code and figure out what's going on without chatting with support.

[virajsoni06]

I agree with a lot of things here at a high level, been facing such basic fundamental issues every now and then. The docs aren't complete and it makes the dev to dig in the code and figure things out themselves which is ironic since the whole point of Swell is to speed up ecomm development.