Closed johnclary closed 4 years ago
Response from BH today:
It actually seems to be resolved at this time, I was able to get in via Chrome today! So nothing to worry about.
i've reached out to BVDW to set a time for screen sharing.
@mateoclarke @johnclary @mddilley My computer restarted after the software upgrade and I tried to log into Data Tracker Prod and still am receiving an error (using Chrome). I tried logging into our other COACD enabled apps and they worked just fine, SMB and Finance & Purchasing (in Chrome). I think something is up with the app, maybe we need to check the code?
After screen sharing with Brian, I was able to replicate the same message that Mateo and I saw on his machine but only with the themed app in a Chrome Incognito window.
Confirm the issue occurs when using our themed Data Tracker page: http://transportation.austintexas.io/data-tracker**
- Unable to replicate in Firefox with/without private window
- Unable to replicate in Chrome
- Replicated in Chrome Incognito (worked on personal MBP with same Chrome version & Incognito, though)
Confirm if the issue occurs when using the Knack out-of-box app: https://atd.knack.com/amd
- Unable to replicate in Firefox with/without private window-
- Unable to replicate in Chrome
- Unable to replicate in Chrome Incognito
Confirm whether clearing cache/incognito work affects anything
- See above for Incognito results for themed and out of the box Knack app
Confirm what happens if user resets their COACD password
- Unable to test on a Mac
Confirm if issue happens offsite/off-network
- All testing was offsite and off-network
Confirm whether the user can login in Chrome using a named user account (not a COACD login)
- Brian was unable to log in with a name user account through the login form here, need to check with @dianamartin if this is possible at all
(might be relevant but doesn't explain why SSO works in Chrome outside of incognito) https://docs.microsoft.com/en-us/office365/troubleshoot/miscellaneous/chrome-behavior-affects-applications
thanks @mddilley. this is a head-scratcher, huh? does anything catch your eye in our themed HTML template? E.g., looks we're using a fairly old version of Bootstrap 4.
The only other thing I can think of that makes this app special is in the SAML config. The issuer is urn:oasis:names:tc:SAML:2.0:metadata
. That's a really weird issuer name, which I used at the time because i was fumbling through my first config. It shouldn't matter, but I could ask CTM to set up a new auth profile for this app with a less weird issuer name.
@mddilley @johnclary I had my issue happen using normal Chrome, not Chrome incognito. I experienced the same error message the users have been getting.
It prompted me to go into the City of Austin log in - I put in credentials and then I get this screen
~Confirmed with Brian that the out of the box https://atd.knack.com/amd worked (forgot to check this in our call yesterday) and he's been working at Cameron Rd on the network.~
Brian followed up and said the following:
I lied. Had changed my default viewer to Firefox, so it didn’t open in Chrome when I clicked on the link. Below is what I get when I log in with Chrome.
@SurbhiBakshi and I just got another report from Paloma at ROW. Chrome didn't work, Firefox was fine.
ugh. also note that @dianamartin is getting this error on the new HR app, which does not use a custom wrapper (in contrast to AMD Data Tracker).
this is gross and i'm fairly stumped.
i think it's time for a knack ticket. what do y'all think @dianamartin @mddilley @mateoclarke ?
Agreed. I'm nervous about Parking needing to log in to the HR app with Brazos/Android. Will they even have another browser?
yeah, if it weren't happening using the OOTB Knack app page, then I was going to start investigating the wrapper code, but that seems ruled out now. I think we should escalate with Knack.
I agree with @mateoclarke. @amenity We'll have to find out what can go on the Brazos devices
pinning this here for future debugging: https://chrome.google.com/webstore/detail/saml-chrome-panel/paijfdbeoenhembfhkhllainmocckace?hl=en
Submitted a support ticket (101489) to Knack:
Note that I was wrong about the SMB app having this behavior.
i compared two POST requests from the SAML exchange. for some users, the redirectUrl
is undefined in the response. when working successfully, the redirectUrl
is defined correctly, e.g https://atd.knack.com/hr?state=p%3DCOACD%26s%3Dhome%26h%3Dhome
.
i won't post the request JSON
here in case it contains tokens.
at first glance it appears to be an issue with the Knack server response, but i suppose it could be happening earlier in the chain, with Azure ADFS
@johnclary - did you want to reach out to someone at CTM to see whether something is happening on the ADFS end of things? Or other next steps? If not, this could go in the backlog. Workaround (using Firefox) has been working for everyone. 🤷♀️
We haven't heard any reports of this lately - probably because everyone switched to Firefox? @dianamartin is going to check with Jenny, B VdW, et al. and test herself.
Testing Results
Just messaged Brian VDW this morning about it, since I saw him "available".
Users to Ask to test Chrome again
Emailed users
We’ve followed up with testing AMD Data Tracker on the chrome browser and it appears that the error messages have resolved themselves. I wanted to ask if everyone could try it again since you folks were the only ones that had “error messages” a few months back.
Please reply and let me know the results via email or Teams message.
Haven't heard any reports of this being a problem; potentially resolved on the CTM side of things.
Some users are getting an error when they try to sign in to the Data Tracker with their COACD credentials in Chrome.
Please work with Billy Howland to reproduce the issue (#2110).
From a user who experienced the issue:
Some test cases: