I currently the latest zeppelin source running in a master server with HDP 2.5, System is CENTOS 7.2. I have also a worker server. Under the master server, the following entry inside the Zeppelin log:
NotebookServer.java[onMessage]:169) - PING message: invalid ticket c89ae223-65ac-2222-1111-fa46122bafec != fbffe895-1111-1111-8d50-67c2b8fbfbf6
and on the browser I can see a JS error with invalid :
JSESSIONID=6c89ae223-65ac-2222-1111-fa46122bafec
So, If I restart the browser in incognito mode the issues does not happen in the browser, but I can still see the log entry in the server. It will remain there until I restart all services and kill all connections.
I ended up disabling the authentication and now the issue is gone (but I have no authentication)
On the other side, the server is behind 2 proxies, one faces the internet and the other a LAN. I am using a similar proxy configuration as recommended by the guide, the only difference is that I am using a url rewrite.
so, the question is: how can I avoid that issue? How can I flush the current sessions of Zeppelin and force a re-login?
Thanks,
Normally that error happens when your session/ticket has expired and you still have Zeppelin tab open and it keeps sending ping messages with old ticket. So for example, when you logged in incognito mode, your old ticket will be invalidated, and if your old tab is still open you'll be getting that error on server. For more details, it would be nice to have your scenario from time your start Zeppelin server in order to reproduce same error case. Possibly some related issues could be under ZEPPELIN-1200, and ZEPPELIN-1298.
Update: it's been addressed under ZEPPELIN-1298
Related
We have a website hosted in the IIS 10 in the Windows Server 2016. It was working normally until today. All of a sudden it stopped working
When trying to browse the site in the IIS via the 'Manage Websites' section, we get the message on the browser that the site can't be displayed
When I try to change http to https I get a different message
When I check the event viewer, in the System Logs section I get a different message
A fatal error occurred while creating a TLS client credential. The
internal error state is 10013.
I looked all over Google, I made sure that all instances of TLS are checked, all permissions are issued to the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder, I checked all the registries and made sure all the proper TLS properties are there.
No matter what I do that error is not going away, and I am unable to view any site hosted in the IIS
Can some one suggest any solution? Thank you in advance
The reason behind the issue is on your machine TLS 1.2 is not enabled.
You can try below steps to slove this issue:
open the registry editor.
go to the below section:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2
set below value to the particular section:
client:
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
Server:
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
restart your machine after editing registry key values.
More information you can refer to this link: https://stackoverflow.com/a/53635769/13336642.
Found the solution. It turns out I had to assign correct certificates in the binding section for the https (443 port)
I have a couple Azure VMs behind a Basic Load Balancer with an HTTP URL Health Probe for the Backend Pool. To mark a server down, that URL returns Status Code 503 (Service Unavailable), but when I call that page from those VMs, the Status Code returned is 403. That still has the desired effect, I suppose, of marking the server down - but I dont understand why the code I set has changed.
This is from an ASP.NET web forms application on the VMs. I look at developer tools in the browser, and from my local machine or from a Dev server on our local network, that page returns Status Code 503, but calling that page from the VMs in Azure, the Status Code is 403.
Here's where I set the Status Code in that page:
Response.Clear()
Response.StatusCode = 503
Response.Flush()
I suppose I should mention that my local is a Windows 10 box, and the server VM is Windows Server 2016. Both are running IIS 10. The application is compiled with .NET Framework 4.6.
Here's the dev tools from my localhost:
Here's the dev tools from the server in azure:
Why the change? Anything I can do to stop this behavior?
So today I tried enabling Failed Request Tracing, but either something wasnt set up correctly, or the error was being handled elsewhere, and didnt result in any failed requests being logged.
Since I wasnt getting any failed requests logged, I opened up Process Monitor and could see that immediately after the call to my Health Probe page, I was getting a call to my custom HTTP Error page. That page must have been what was giving the 403 (dont know why, b/c that page works correctly for other HTTP Errors with a friendly error message and logging of the error to my custom error tracking solution).
I was going to change the Status Code to see if there was something special with the 503 that I was setting that was handled differently in IIS, but that got me thinking about how I was setting the status code...
In my research today, I saw this page https://www.leansentry.com/HowTo/AspNet-Response-Flush-Poor-Performance which cautions against using Response.Flush(). The code that I had implemented was in the Page_PreRender method, so there's not really a need to Flush there anyway.
I removed the Response.Flush and of course, my troubles went away.
The Health Probe page no longer triggers an Error from the Azure VM, and therefore, the status code that I get in my client browser is the 503 that I set in code.
So I guess this case is closed. I will need to figure out why the HTTP Error page was throwing a 403 instead of returning the friendly error message, but that should be easy enough...
I have an ASP.NET MVC 4 app (.NET 4.5) and SIgnalR works fine with forms-based authentication (hosted via IIS/IIS Express)
As soon as I change the app to windows-integrated authentication (<authentication mode="Windows"/> in "web.config") it stops working.
jquery.signalR-2.2.2.min.js:9 WebSocket connection to ws://localhost:51030/signalr/connect?transport=webSockets&blhablahblah failed: Error during WebSocket handshake: Unexpected response code: 403
After adding the [Authorize] attribute to my hub, the error changes to
WebSocket connection to ws://localhost:51030/signalr/connect?transport=webSocketsblahblah failed: HTTP Authentication failed; no valid credentials available
Other parts of the app are working just fine, windows-auth is enabled on the server and works, etc. etc.
How do I solve this?
And if it is unsolvable for some reason (it could be Chrome not supporting windows auth on websocket connections or something else) - why doesn't it fall back to non-websocket protocol? and how do I force the fallback?
UPDATE: I created a github issue https://github.com/SignalR/SignalR/issues/3953. The problem is not that I can't connect. The problem is that I cannot handle the error to fall back to another transport. Neither .fail() not .error() are being invoked. Try-catch doesn't help either.
Update from 2020: looks like Chrome now supports NTLM on WS-connections, not an issue any more
...10 hours later after asking the question...
Partially solved (answering my own question)
After playing with it I can confirm, that adding the [Authorize] attribute to my hub (or alternatively, adding GlobalHost.HubPipeline.RequireAuthentication(); to your "Startup.cs") actually does help. It does fall back now to an alternative transport, even though the error is still thrown into the browser's console.
You can also specify which transport it falls back to, by calling:
$.connection.hub.start( { transport: ['webSockets', 'longPolling'] });
in case you don't like the default priority (I guess, "hidden iframe" is the default second option).
The reason
The error is caused by Chrome, it does not support NTLM on websocket connections. Funny enough, IE, MS Edge and Firefox do support it ("Chrome is the new IE" huh).
There's an open issue in Chromium bugtracker for this here https://bugs.chromium.org/p/chromium/issues/detail?id=423609 if anyone wants to add any input to Chromium devs.
I too was experiencing this error, but only when developing locally using http; I think Chrome doesn't like unsecured ws:// connections. Once I deployed to server with secure https connection, the WebSocket connection was upgraded to wss://, and Chrome stopped complaining, worked fine with WebSockets--didn't have to fall back to other transport.
tl:dr; Make sure to use https for your site.
Migrated a fully-functioning Drupal 7 site and corresponding database to a new server. I am unable to login to the admin side. The error message is: “Access Denied. You are not authorized to access this page.” The username and password has been verified.
I looked at /admin/reports/dblog, the error log shows 2 entries per login. One entry shows the session is opened for the correct username, and the other entry shows access denied and the user is ‘anonymous.’ It is my assumption that Drupal is not able to validate the user so it is assigning the user as anonymous.
I read many forum topics on similar issues. I commented out the ‘$cookie_domain’ in ‘settings.php’, but still nothing. I looked back at the functioning site and saw that 2 cookies are generated: ‘has_js’ and a session ID cookie. In the new site, only the ‘has_js’ cookie is generated (using both Firefox and Chrome browsers). I have verified that the session id is being saved to the session table in the database.
I have looked into modifying ‘php.ini’ (etc/php5/apache2/php.ini) but have not found a solution that saves the session id cookie.
Drupal 7
Linux Server
Ubuntu 12.04
Apache 2.2.22
MySql 14.14
PHP 5.3.10
Uncomment line 340 on settings.php to reflect your domain name
e.g. for localhost
$cookie_domain = 'localhost';
Please note this works for drupal 7 and my php version is 5.6.
Regards,
When migrating drupal installations from server to another there is several problems that could appear.
1) check your file permissions, because sometimes we migrate files from server to another and having different owner:group and this gives serious problems.
2) You need to delete all cache before migrating to avoid having access problems and using wrong urls from cache and so on, in your case you already migrated Drupal, so you need to go to the DB and delete content of all cache_* databases. this could help you.
3) if not you need to look at what php version you have been using and mysql and apache maybe some deprecated functions or so.
I had the same problem, except that I could see the session cookie in Chrome (Settings -> Show Advanced Settings -> Content Settings -> All Site Cookies and Data). The cookie's "Send for" property was set to "Secure Connections Only" and my site was running up on HTTP / port 80. Thus the browser would not send the cookie back to the web.
The problem turned out to be this line in php.ini: session.cookie_secure = 1
When this option is set, PHP will specify that the cookie may only be sent over a secure (HTTPS) connection. This makes it harder to mount a man-in-the-middle attack because the cookie is no longer sent via clear text.
There are two ways to resolve the issue: 1) Switch the site to HTTPS. 2) In php.ini, set session.cookie_secure = 0
I had the same problem. Number 3 from the first answer saved me - I'd recently changed my MAMP PHP version to 5.6 and this seemed to be causing the issue. Reverting back to 5.5 means I can now login.
All of a sudden all of my websites on my server return 400 Bad Request Error. I don't have a clue what happened. App Pools are running in Classic pipeline mode (4.0, 2.0), doesn't matter.
Every URL that I type comes back as 400 Bad Request. Real URLs, even fake URLs that don't exist (which should come back as 404) all are 400.
http://mywebsite.com/AFile.aspx
http://mywebsite.com/AFolder/AnotherFile.aspx
http://mywebsite.com/Bfolder/YetAnotherSillyPage.aspx
http://mywebsite.com/A_stupid_URL_that_does_not_even_exist_fjfjffjfj.aspx
Everything 400 Bad Request. Totally screwed up my ASP.NET. Where should I begin to look? Machine.config? Web.config?
UPDATE:
After trying a million different settings, I finally set the App Pool to Integrated and set the Identity to LocalSystem and all of a sudden it works.
Bad Request usually is HTTP.sys stopping the request due to something really bad (like invalid URLs, or something like that).
You probably should look at HTTP.sys logs (Not IIS) at:
C:\Windows\System32\LogFiles\HTTPERR
Also, maybe something got broken in the http.sys configuration so try running:
netsh http show servicestate
And see if for your web site it has the correct bindings, for example it could be that the bindings are only listening on only specific IP Addresses and yet its coming from another one, or similar problem but with Host Name, etc.
Finally you might want to run:
C:\Windows\System32\inetsrv\appcmd list sites
And see if the bindings and status makes sense.
Have you tried some mixture of re-installing (or uninstall/install) asp.net using the aspnet_regiis.exe utility? That's fixed strange IIS/ASP.NET server issues for me in the past.
Have you looked in the event log for any error messages or further clues?