Strange thing happening to me.
Every time I load my SOLR admin page, the developer console shows me that a XMR.OMINE.ORG virus is trying to inject a JS in the page.
That happens 1000 times and makes the page hang.
What is strange is that it happens ONLY when I access the SOLR admin page and not with any other page on the same web server or an internet page.
I tried everything...nothing works.
Here is the console log:
A parser-blocking, cross site (i.e. different eTLD+1) script, , is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See for more details.
VM41 v7.js:1 [Violation] 'setInterval' handler took 280ms
VM1939 v7.js:1 WebSocket connection to 'wss://xmr.omine.org:8181/' failed: WebSocket is closed before the connection is established.
I tried:
Running AVAST for MAC -> the web shield detects the virus but the scan doesn't and it doesn't remove it
Malwarebytes for Mac -> nothing found or removed
Running antivirus on web server => ongoing
When I access it from another laptop => it works, no injection => CORRECTION, same problem on other machines, seems server-related
I'm lost, I can't run the SOLR admin and I have 504 errors on SOLR updates
Can you help me please?
Nico
Related
I am developing a .Net Core (3.1) web application hosted with IIS 10. When I am trying to use SignalR on localhost, I am able to connect totally fine and receive messages from the backend, but after I publish it to IIS, I get the error: "Server returned handshake error: Handshake was canceled." In the client logs on Chrome's console, I get the message: "Information: SSE connected to http://myserver.com/MyApplication/output" before I get the error described above (which you would think means that I connected successfully)...
I have seen other posts where people have suggested that I have to enable webSockets on IIS, and I have already checked the my site has this enabled.
I have also seen people suggest to try using the longPolling argument in the withUrl function when creating the connection, and this has not helped either.
I have also added SignalR Event Log Trace Listeners to my web.config file, and the only warning I get that might be related to this issue is that I get a warning from the .NET runtime that reads "Failed to determine the https port for redirect." I am not sure what this means or if it would be related to SignalR, but as this also appears to deal with Middleware, it might be significant.
One thing that I thought might be related is that my site is just one of multiple hosted on this server, so that when I am running locally, I can use the following to connect to SignalR:
hubConnection = new signalR.HubConnectionBuilder().withUrl("/output").build();
But because of the way this site is deployed on my server, I have to use this:
hubConnection = new signalR.HubConnectionBuilder().withUrl("/MyApplication/output").build();
when I deploy the site or else I get a 404 error...
Would there be any issue there? I noticed when inspecting the network requests that on localhost, the URL to connect with the socket is "wss://localhost:44315/output?id=..." and I get the "Status Code: 101 Switching Protocols", but after I deploy, the url that is used is "http://myserver.com/MyApplication/output?id=..." and I get a "200 OK" just before receiving the error described at the top. Why does wss get used on localhost but http is requested from my client when I deploy?
FINALLY discovered the issue after days of debugging... The reason I was getting a "101" response on localhost and not when published is because 101 is basically the server (IIS in my case) saying "I support web sockets". I realized that because I wasn't getting this when published, web sockets were probably not enabled in IIS. It was weird, however, because I went into IIS manager and it said that web sockets were enabled, but after much more research, I found that you also have to go into "Server Manager" and enable it as well (see here https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support and follow step by step instructions). I did not realize both were required.
I have been recently stuck into a strange issue, thrown by a Multi platform Hybrid App in Visual Studio App.. My Development Environment details are as follows :
Visual Studio 2013 Release 3
Cordova 4.0
Angularjs 1.4
Ionic 1.4
Nokia Lumia 1320 [Windows 8.1 OS]
I have a web app that will be interacting with the mobile app, deployed on a server machine that can be accessed both by an internal enterprise network, as well as from internet.
Now the problem is, when i am [the mobile device is] connected to the internal network, the $http call fails with a status code of 0. Internal dig down reveals that the actual returned status code is -1.
However, when i switch over to mobile data in the phone, the ajax call goes smooth and finishes successfully. Now, if i switch back to internal network, it again starts working perfectly. !!!!
The http call is quite simple and uses promise API... I also have some request interceptors.
Any explanations for this strange behavior, or more appropriately a solution for the same ??
After Scratching my head for over 2 days, i was finally able to conclude that it was my browser that was the culprit.
As i said, i was using Windows Phone 8.1, which uses Internet Explorer 11 as the default rendered. Also, My Web server was actually behind a Proxy Server [Apache HTTP].
Now, the Real problem was that the ajax call was returning response status code as 0. And the reason for that was that The Ajax Call was being suspended by The Apache HTTP Proxy Server, because of some tunneling issue. Please note that this was specifically happening with IE11 and Apache HTTP Server.
This was happening since I was using POST request on a HTTPS Based Proxy Server.
Now the solution is too non-technical, but that's what saved my life. In order to save your life from this issue, You must
1. Either convert your POST Request to GET Request
2. Or Before making a POST Request to the Server, make a GET Request to the same server.
In my case, i went with the second approach and it saved my life. Posting this as answer so that it saves someone else too.
You can refer to the following links for more details.
IE10/IE11 Abort Post Ajax Request After Clearing Cache with error “Network Error 0x2ef3”
Making XHR Request to HTTPS domains with WinJS
We have a deployed java application on GAE. We have enabled SNI SSL certificates. For the last few days, we have observed that that any HTTPS request that are taking more than 2 seconds are getting aborted by server (as reported by browser). This is consistently happening on FF, IE and Chrome on Windows XP, Windows 7 64bit & Safari and Chrome on Mac Mountain lion. The error that is shown on Chrome is "Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data", where in IE (v9.0) is throwing error 12152.
This was consistently reproduced by hitting a URL, mapped to a java servlet, which is made to sleep for >=2000 ms. The sleep interval was given as a request parameter and tried with varied value of 1000 to 5000 ms. The above mentioned error was thrown for all values >=1900 ms, while any thing less than that would not yield any issues.
However, there were no issues faced if the URL scheme is changed to HTTP.
GAE application logs did not show any error or any signs of new instance spawning off. We are App engine version 1.8.1 and java version is 6.
Any ideas to solve the issue would be immensely helpful.
Edit: The issue is only there for custom domains. It works fine for appspot domain. (xxxxx.appspot.com)
Sreejith
That error is widely known and is related to your internet cache (see the bug report for Chrome, for example).
After a quick search, everybody seem to agree that these solutions could fix the problem
clear your browsers cache (maybe use some external programs)
reset your browsers preferences to the default ones
uninstall and install again your browsers
Some other people suggest to perform a system restore, but that seems too extreme to me.
I need to understand a complex web project and for that I need to be in a debugging session for much longer time. For this I have set the "Application Pool" "Ping Enabled" to False in the IIS 7.5, so that IIS does not terminate itself and I can continue debugging.
But, if I continue debugging for a longer time, I do not receive the response in the browser, rather I receive a blank page. Although there was no exception raised while debugging and everything went properly.
What other configuration is needed to remain in a debugging session for a longer time?
Can anyone suggest?
There are two timeouts that you must consider, both the server and the client.
You have already resolved the server timeout but the client (browser) gives up and shows a white page, usually after 1 minute.
You need to increase the timeout that the browser is willing to wait for.
There are steps to do this in IE here: http://support.microsoft.com/kb/813827
Background
We currently have a SilverLight form that posts data to a second common form that multiple applications use, which then runs the need business logic to place the data into a database.
We have several national and international offices where this form is used.
There is one office location (CO) where this form is consistently producing intermittent error messages and based off log data, it is only happening in this office.
Error Symptoms
Initially users will typically report that there is an error and when I log into their machine using MS Communicator, 80% of the time it would start working.
I started installing Fiddler on their machines to try and capture more information but 100% of the time I did that, the form started posting successfully. The users being resourceful, simply start Fiddler anytime the form doesn't post and it works fine.
I also asked users to go through Citrix which is hosted in the TX office and the form posts fine.
Error Details
I used OPNET to better monitor the traffic and I found that when user's simply open IE the authentication handshake fails.
Client => Server = 401
Client <= Server = Authentication Token
Client does not respond
When we use fiddler, the handshake is successful.
The error returned by SilverLight was a very generic [HttpWebRequest_WebException_RemoteServer] message.
Question
What would cause the handshake to work sometimes by itself, always with fiddler and CITRIX, and sometimes it doesn't.