Odd one this. I've got a servlet application running under Tomcat with Axis2. The application also exposes a web service (via Axis2).
Now then, Tomcat handles session management no problem, as per usual, however, when the web service is invoked, randomly, all sessions appear to be invalidated. Plus, afaik, this only happens in Chrome! The next time the Chrome client makes a request, it is handed a new session by Tomcat.
This happens after every time the web service is invoked, but doesn't affect sessions in Firefox or Safari.
Any ideas? This is extremely baffling for me.
Thanks in advance
Fixed it. Very strange result but the Axis2/web service part was a complete red herring. The problem here was that I was using another instance of Chrome to invoke the web service (using a different web app).
This second app was running on the same URL but on a different port (8080 instead of the default 80). It would seem that browsers (not just Chrome) manage sessions based on A. the domain (such as www.stackoverflow.com or localhost in my case) and B. the path (ie the name of the web app in Tomcat).
It does NOT make any distinction between domains running on different ports, hence Chrome got itself all confused when I had two windows open, one pointed to localhost/webapp and the other pointing to localhost:8080/webapp. As far as Chrome was concerned it was the same site and therefore each one kept overwriting the other's session ID.
What a mess!
Related
I am running two Windows server 2016s with IIS 10.0.14393. One server for staging purposes, and one for production.
The application has one "front-end app" and one "back-end REST api" running on the same IIS server. The front end communicates with the backend (suprise!). The difficulty I am facing is that the staging server works as expected, i.e no "Sign in" box appears when entering the front-end web page (React). However, on the production server this box pops-up.
When the page is loaded, there is javascript that fetches some information from the API, and it seems that this async fetch is causing the pop-up to occur (the request is in pending mode until login).
I have studied the configuration of IIS on the two servers but can't seem to find any obvious differences.
Both instances have both windows authentication and anonymous authentication turned on for both front-end and backe-end. I need this as the API has different types of authentication for the endpoints.
Anyone that has solved a similar issue?
Thanks
If someone experiences a similar issue the following link may help: https://support.microsoft.com/en-us/help/258063/internet-explorer-may-prompt-you-for-a-password
In my case I was sending the request to the api with the full domain url. The problem was fixed by just using the machine name (and port in my case) when sending the request. If the whole domain with punctuation is used, the system believes that the request is meant for the Internet and not the intranet, and will not include any credentials.
Another, and probably more robust solution, is to add the site in question to: Internet properties -> security -> Local intranet -> sites -> advanced.
We are using .localhost domains for development of our applications, and we have multiple applications living at different domains. We are at point where we need to test features requiring pages to execute in Secure Context, i.e. Service Workers and Push API.
Google Chrome for a past few versions has been marking all sites coming from .localhost domain as Secure Context, allowing local, hassle-free testing of Service Workers, Push API, etc.
I cannot find a way to force Firefox 76 to consider same pages being from Secure Context.
We have managed to resolve all .localhost addresses correctly to 127.0.0.1 in all browsers using local dns-resolver settings or built-in browser behaviours.
Firefox config entry network.dns.localDomains does not seem to affect if site is considered to be in Secure Context.
There seems to be some kind of FF internal development to change that behaviour out-of-the box, but it's hard to say when it will be merged and released, and if all pages in *.localhost will be considered Secure Context for sure:
https://bugzilla.mozilla.org/show_bug.cgi?id=1220810
As of Firefox 84, localhost is considered a secure context. Before that, it wasn't because it's not guaranteed that localhost will in fact resolve to a local (and therefore trusted) address.
However, the preference dom.securecontext.whitelist (renamed to dom.securecontext.allowlist in Firefox 97) has been created specifically with this scenario in mind, and it takes a list of origins (for example, host1.example.com,host2.example.net) that will be considered secure.
This preference does not seem to be well-documented, but it can be seen in this changeset: https://hg.mozilla.org/mozilla-central/rev/cfb9de0c9f2a.
I got a Glassfish 4.1.1 copy with two domains on Win2012R2 (no clusters, no instances). I've set a windows service for each of those.
Both services run regularly up until the moment when I restart either or both of them thru their admin web console (server (Admin Server) -> Restart). The following happens:
The domain-related service stops, but does not start again,
The allegedly stopped domain is perfectly functional (deployed apps and admin console are there) (!!!),
When I try to start the win service manually, I get Error 1067 (GF reports "something" is already listening on required ports and that's the domain itself that is now, somehow, NOT run as a service!),
I can start the service again only after I've stopped the domain thru server (Admin Server) -> Stop.
Why did I mention two domains? Because this does not happen when I have just one domain with its' service.
Domains do not share ports, only things in common are the JDK/JRE and general GF files.
Is this a bug in Glassfish or did I set something wrong?
This is a limitation, rather than a bug. The problem is that GlassFish has no way to tell whether or not it is running as a service (and, if it is, what the name of that service would be).
The restart command means that GlassFish is restarting itself, so Windows detects that the process it started has been terminated and shows the service as stopped, but GlassFish spawns a new JVM itself. It has no capability to tell Windows to start the service again.
Essentially, the behaviour you are seeing is expected.
After some more testing, I realized what was going on:
Glassfish is definitively capable of restarting its' own Windows service,
The thing that was happening is it takes GF a few seconds do this on its' own,
But, before GF domain could restart as a service, I clicked the URL to return to admin console, every time. That forced it to run as an ordinary executable.
It does seem like the restart happens faster with just one win service, but I won't claim that as an absolute truth without more testing, for which I have no time now.
I have three mvc 3 web applications in a single web role on Azure Cloud Services. All of a sudden this morning both the single instance in production and in staging give "HTTP Error 503. The service is unavailable." when navigated to in a browser.
I rebooted the production instance but nothing changed. Then I deployed a remote desktop enabled version to the staging instance and logged in. However, strangely when I navigate to the web applications in a browser inside the remoted staging instance everything works.
Looking at IIS server logs it seems there are some issues starting the roles (warning level about the appPoolId being incorrect) but obviously the roles are starting as they are accessible from inside the staging server.
The World Wide Web Publishing service is also running and even after restarting this service the web application is not accessible externally.
Does anyone have an explaination for why the sites are accessible locally but not remotely that would help me debug this issue?
I found out where the issue came from, the bindings that were configured in IIS7 did not include bindings for the actual [abc].cloudapp.net host headers.
I assume that for some reason since some time last night or this weekend the requests seem to come with those headers instead of the original headers for the website. This is really strange but adding these bindings fixed both the staging and production instances and they were available again after this change.
I'm using the AJAX Test Server in Rational Application Developer. I'm posting a form to another host for authentication. That host takes a URL to redirect to after authentication. However, it insists on using HTTPS whenever it sends the 302 response. The low hanging fruit would be to just use HTTPS locally.
Looking at the launch configuration, the AJAX Test Server appears to be a custom Apache HttpCore server. I haven't spotted anything in the configuration guide.
Is there a way to access this test server via HTTPS?
This is for demo and local development purposes; not production.
Speaking from working with WAS (WebSphere Application Server) in RAD, I'm pretty sure the answer would be yes. The server (at least with WAS) has both secure and "unsecure" ports.
What I have noticed is that when the server is built with the install (at least with the newer versions of the products 7.5+), the ports used are different per install. This is to help with not conflicting with other applications that may use those ports.
So https is probably fine. You just may have to use it over port 302 or some other port.
If there is no admin console for viewing your ports, you could always try the Window | Preferences option under your menu items. Sometimes IBM hides server config stuff in there.