I have an odd okta issue.
I have a old Web Forms app that I am integrating with okta.
The problem is after I login using okta, okta navigates the app to https://domain/authorization-code/callback. This is the value in the address bar of the browser. The app is not automating navigating to the call back page (my default.aspx page). See screen shot below.
Here is what is really confusing, this issue only happens in Production and in browsers: Edge and IE. For Production, everything works fine using Chrome. (After I log in, I am navigated to my default.aspx page).
Additionally what is confusing is everything also works fine in Dev, QA and UAT using Chrome, Edge and IE.
This issue only occurs in Production, using Edge or IE.
I assume it is not a browser issue / setting since it works fine in the other environments. Plus I assume it is not a server side setting since it work fine in Chrome in Production.
Any suggestions would be appreciated.
Plus suggestions in how to debug. I am trying to use the Network tab of the Developer Tools, but I not having much luck.
Thanks
We fixed this problem, months ago. It was because Production is https and QA and UAT were http. I updated the urls in the General tab inside okta to https and everything started working.
Related
So I just linked my custom domain with firebase and it shows connected:
image of connected status
which is great. But now when I search website without /index.html, it redirects me to this page. I want to see this page which is accessible only when I append website domain with /index.html. I am new to firebase. How can I make my domain access index.html page without specifically mentioning /index.html?
EDIT: I just noticed that it's working fine on the mobile devices and in the incognito tab on PC. It must be something with my chrome browser I am logged in with. which is weird :/ should I change the title? Cause I think fault could be related to browser. but help me if you can.
So the real issue wasn't the configuration but the browser cache. if you are facing similar issues then try clearing the browser cache or try browsing the website on a different device. Spent literally 1-2 hrs on such a silly problem. Either way, thank you.
I have configured my Websphere Liberty server to support the Admin Center as described in the IBM Knowledge center.
I am running WAS Liberty version 17.0.0.1 on Windows 10 from an eclipse Neon environment (ie. on localhost). I connect with the URL (http://localhost:9080/adminCenter) from Chrome (version 61).
It puts up a login page (not great looking but serviceable)
I enter my credentials and click Submit and I am taken to the login.css webpage.
Within the Chrome developer tools, I can see an error message on the console indicating the GET for favicon.ico failed.
Then I can go to the browser address bar, manually change the URL to point to the adminCenter and it takes me to the Toolbox page for the Admin Center. From there I can select the Server Config graphic and see my server data.
Can anyone identify what I have configured wrong that is causing the AdminCenter to display the login.css webpage rather than re-route to the adminCenter webpage after I login?
Additionally, if anyone can direct me to instructions on how to put up a more user-friendly login page, I would be very grateful. (I'm doing my client-side application development in Angular. The only information I've found so far for customizing a login page with WAS Liberty references creating a login jsp page which I don't know how to do. (Sorry, I don't have enough reputation points to provide the URL for this) I'm still learning Angular and client-side development.)
Have you previously accessed a different version of Liberty and accessed its Admin Center on that browser? If so, your browser (or something else in the network pipe) could be caching old files causing such issues. When something like that happens, easiest way to check would be to try and open the page (the url you're using is correct, and it correctly redirects you to HTTPS) in a private/incognito tab/window of the browser (ctrl+shift+n for most browsers), or a different browser. Alternatively, you can clear the cache of the browser you're using for that page/domain (which would also be the actual fix if the cache is indeed the problem.)
I recently moved by site to https and i have many users from xp and ie8.
Just noticed website with https not working as per screenshot below:
AS per my research on similar topics:
http://support.microsoft.com/kb/968089
Microsoft says, you cannot view the site until you make some changes into your browsers, which is not possible to explain to every user who has IE browser.
Similarly, when i view Google on ie8 it works fine, so any one guide me what is the solution?
any help would be appreciated.
I have a number of virtual applications under one site, all of which have the same issue. Whenever you are at the root of the application (~/) postbacks do not fire, the page just refreshes.
Here are some samples (all their own virtual applications):
Clicking on "Login" link does not redirect to Login.aspx page
http://designbyssi.com/designbyssi.com/projects/air-savings/02/
http://www.designbyssi.com/designbyssi.com/projects/life-furniture/06/
Entering username / password, and then clicking "login" / "go" does not log a user in
http://designbyssi.com/designbyssi.com/support/
http://www.designbyssi.com/
For some reason, if you add "Default.aspx" to the end of any of the pages above the postback works as expected (eg. http://designbyssi.com/designbyssi.com/projects/air-savings/02/Default.aspx). I've been Googling this for a while now and I found a few articles, though none of them have helped.
Here are the articles I've managed to find:
Why won't postbacks work on my domain root?
http://forums.asp.net/t/1735380.aspx/1
http://forums.asp.net/t/1482960.aspx
I'm not using any type of URL rewriting, they are all web form applications, and I'm on a Godaddy shared hosting account.
Any ideas on what might be happening, or what I need to do to fix it?
I had the same issue recently where my dev environment was setup in integrated mode while production was in classic mode. Postbacks in dev were not working when going to the root of the site but would work when going to Default.aspx.
I simply changed my dev environment to use classic mode for now. Also, this problem does not necessarily have anything to do with URL rewriting.
Since you are on shared hosting, you probably can't do that but these links may help.
Postback doesn't work with aspx page as Default Document
Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode?
I have noticed that when my internet connection is a bit slower all my wp sites take up to five minutes to load Google Chrome when I am logged in. The version of google chrome I am using is 17.0.963.83.
When I logout the site loads fine again. The dashboard also loads fine when I am logged in and I know it's not a problem with my theme because the same thing happens applies when I apply the default twenty eleven theme.
I have set up a dummy subscriber user so you can test it yourself (to see the difference between the logged in states you need a slow connection though :p)
h2euro.org/wp-admin
u: testuser
p: test
Does anybody have an idea why this is happening?
When logged in, it loads "aloha.js", which is almost a megabyte. Found using Chrome's dev tools, 'network' pane.