Closed Lowell-Syncrety closed 4 years ago
...I suppose if the app is just a window into the web portal that link should only show up if someone's using the app, hope that would be possible.
It is already web app inside a browser for desktop portal. which version are you using?
For version 2.x, we deploy portal code with browser, now its only browser. So that portal doesn't have to redeployed when portal been updated.
Which also means, if portal functionality is broken, then web is also broken. Is your customer's portal still on 2.x or 3.x?
We're using 3.x and when testing at our site our portal is also 3.x. I just shutdown the app and restarted it, and the button works. So we'll probably have to send out a mass reboot tonight for computers.
Weird, portal didn't change any functionality regarding to submit ticket. Not sure why its failing on submit ticket.
Same request type? Not the case that user no longer have access to request type?
It was well before that; "Create a New Ticket" right at the main page. Restarting the app helped. But Reload just took us back to the sign in screen, which would be too confusing for most people. Maybe something changed in the way that the current "session" timed out and that's why Reload came to the sign-in screen. So far seems to be affecting computers that have been running the app for more than a day anyway.
I found why it went to login page on portal after reload. I will fix it in next few days.
If you encounter create ticket not working issue again, could you use ctrl
+ shift
+ i
to bring up developer panel. To see if there are any failed network request there when you click around. Get as much detail as possible, so I can nail down the issue.
Useful information are:
So I can replicate this on various machines we haven't restarted the app on... going to Network there are various red Status 401 lines when I click on Create a New Ticket, for the /RequestNewSupport call. Want me to email that to you directly? Or I could find out my colleague's ticket number and add the data there.
If you could send those information to me would be great. Just pick one of 401 request and get those information I described there to me.
Also copy over the cookie from the request. I will use it to test locally to reproduce the issue.
@Lowell-Syncrety . I believe I have resolved the issue, the fix will came out within next two weeks. This will ensure in the future this will not happen again.
What happen is we have logic to change cookie signing key every 6 months, and retire old key in a year. Those logic are correct, when use key to identify cookie is valid or not ignored key between 6 and 12 months old. Which that should not happen.
For your case, the cookie is signed with key that's created half year ago, where two days ago new key been created, the logic prevent old key from used to verify cookie. That cause request to fail.
Thanks for help out on diagnose
@Lowell-Syncrety just let you know, I have just released a minor change to portal, when reloading in desktop portal, it should navigate back to landing page, instead of login page if user already logged in.
Great, thanks!
We use the DD Portal app on all computers for all customers, but have to also keep reminding people it's available online in their web browser if they're using their phone, or if the app isn't working. Currently there's an issue that the "Create a New Ticket" button doesn't work for anyone in the app. I'd like to see a link in that main screen added that would say "open the web portal in your browser" or something like that. This would reinforce the concept that they can always use a web browser as well, but in cases like this they could try the web browser if the app is broken.