Skip to main content

Support for passing session token in URL removed??

llppa-2124
Original Poster

We have 2 integrations that generate PDFs from an add-in in Geotab Drive, and to do it, we leverage this kind of link:

 

https://my.geotab.com/test_database/#hosLogs,dateRange:(endDate:'2019-10-28T17:46:00.885Z',startDate:'2019-10-14T04:00:00.000Z'),driver:b12345,includeExemptions:!f,includeIntermediateLogs:!f,token:('userName':'johndoe','sessionId':'asdasdasdasdasdasdasd','database':'test_database')

 

This has worked for 6+ years. Today when we generate the PDFs, customers have started getting blank pages. When I try to replicate in chromium locally, I am directed to the login screen. Has support for this kind of link been revoked?

I tried to workaround the issue by setting geotabAPI_credentials and geotabAPI_server in localStorage, then navigating to the base URL, but still I am getting directed back to login. This might be related to the move to CIAM and oauth, but there was no communication around this change and support being removed. We use this daily and 30K+ drivers depend on it for compliance. Please advise.

Join the conversation

You need to be logged in to reply to this post and participate in the Geotab Community discussions.

8 Replies

EDIT: Tested the link in my database and it seemed to work how I would expect. My guess is an issue with the link structure or one of the parameters being passed.

 

When you get directed to the login page, do you see any messages about the session? If a session expires or is otherwise marked inactive, you'll see the login page.

 

Have you looked at the results of the page call in tools like a browser's Developer Tools window or Postman? It might be a good lead if you're getting something other than a 200 in response (a 401 would be a big clue).

llppa-2124
Original Poster

No message, just a redirect to login. As if session information was never sent.

Probably should have done this before my first reply, but I just in my database using your exact link, and it took me to the HOS log page without issue. My steps were:

  1. Authenticate a user to get a fresh sessionId
  2. Replace values in your link for those in my environment
    1. Database in URL
    2. Driver ID
    3. userName, sessionId and database in token
  3. Navigate to that link in my browser.

 

I was taken to the HOS Log page for the given date range.

llppa-2124
Original Poster

When you tested the link, were you in a private browsing window? Otherwise in a browser, it might just be re-using your previous session from that browser. If it does indeed work for you in a private browser, and it stopped working for me, maybe it's because your database or user has not been migrated yet. For us it was working up until yesterday.

 

Thanks for stepping in to help btw.

No problem! I hadn't actually done that originally (and it's a good catch to suggest that), but after trying again in a private window I get the same result. It automatically handles the authenticate and redirects to the HOS Log page.

 

Where is the URL being used in your integration? My next best guess is that something about redirect handling might have changed.

llppa-2124
Original Poster

For me this exact same procedure fails now on both databases I've tested. I have an open case with Geotab support to confirm if moving to CIAM progressively breaks this kind of thing.

Good luck, I'm interested in what you find. Just in case it helps, here's the version my database reports (Support -> About):

 

image

llppa-2124
Original Poster

I'm on the same with failures.

11.123.501-acd8adccb4e6

Still have questions?