I have Apache superset version 1.2.0 in docker (Ubuntu 18.04), Frequently I am getting a 504 error on one of the dashboard,
I have added SUPERSET_WEBSERVER_TIMEOUT = 300 in superset_config.py,
Still I am getting the same issue. Any suggestion please.
Error Message:
<html> <head><title>504 Gateway Time-out</title></head> <body> <center><h1>504 Gateway Time-out</h1></center> </body> </html> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page -->
Long running query(mins - hours) requires Celery workers since web request timeouts are within 30-60 seconds.
Related
After updating WSO2 IS using U2 I can see the following intermittent debug log when I try to log in to my SP.
TID: [-1234] [] [2022-12-05 22:13:30,322] [bcc826e3-5dcf-4a14-8048-6fd6b59d4599] DEBUG {org.wso2.carbon.identity.application.authentication.framework.AbstractApplicationAuthenticator} - Error occurred during the authentication process, hence retrying. org.wso2.carbon.identity.application.authentication.framework.exception.InvalidCredentialsException: User authentication failed due to invalid credentials
...
at org.wso2.carbon.identity.application.authenticator.basicauth.BasicAuthenticator.processAuthenticationResponse(BasicAuthenticator.java:699)
at org.wso2.carbon.identity.application.authentication.framework.AbstractApplicationAuthenticator.process(AbstractApplicationAuthenticator.java:89)
at org.wso2.carbon.identity.application.authenticator.basicauth.BasicAuthenticator.process(BasicAuthenticator.java:141)
at org.wso2.carbon.identity.application.authentication.framework.handler.step.impl.DefaultStepHandler.doAuthentication(DefaultStepHandler.java:512)
at org.wso2.carbon.identity.application.authentication.framework.handler.step.impl.DefaultStepHandler.handleResponse(DefaultStepHandler.java:486)
at org.wso2.carbon.identity.application.authentication.framework.handler.step.impl.DefaultStepHandler.handle(DefaultStepHandler.java:180)
at org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl.DefaultStepBasedSequenceHandler.handle(DefaultStepBasedSequenceHandler.java:186)
at org.wso2.carbon.identity.application.authentication.framework.handler.sequence.impl.GraphBasedSequenceHandler.handle(GraphBasedSequenceHandler.java:113)
at org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultAuthenticationRequestHandler.handle(DefaultAuthenticationRequestHandler.java:159)
at org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator.handle(DefaultRequestCoordinator.java:249)
at org.wso2.carbon.identity.application.authentication.framework.servlet.CommonAuthenticationServlet.doPost(CommonAuthenticationServlet.java:53)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:681)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
...
And I cannot proceed to my SP in the browser.
How can I fix this?
The above issue can happen if you have updated the IS using either WUM or U2 tools. If you open the network tracer of the application via your browser, you can see there is an error when loading the jQuery library. This is the root cause of this intermittent error.
To solve this, you should replace every .jsp file (residing in the <IS_HOME>/repository/deployment/server/webapps directory) containing the
<script type="text/javascript" src="libs/jquery_3.4.1/jquery-3.4.1.js"></script> with
<script type="text/javascript" src="libs/jquery_3.6.0/jquery-3.6.0.js"></script>
which is the new version of your jQuery library in the IS.
Currently, the above issue is occurring with jQuery 3.4.1 and it can be fixed with replacing the script tags related to jQuery loading. But if the jQuery version changes, you have to find the exact jQuery version by going through the webapps.
I have moved my OpenCart store to a different host (by restoring CPanel backups - home directory, MySQL database, email forwarders), changed my config.php accordingly, and everything seemed to work normally on the front-end. However, I am experiencing some major issues that affect crucial parts of the store.
First off, whenever I try to log in to the admin panel I receive the following message (as a javascript 'alert' popup):
SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
OK
Followed by the raw HTML code of the admin login page:
<!DOCTYPE html>
<html dir="ltr" lang="en">
<head>
<meta charset="UTF-8" />
<title>Administration</title>
<base href="https://[MY STORE URL]/admin/" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0" />
... etc
When I am trying to move around between different sections of the admin control panel I am constatly getting logged out, and receive the same error upon logging back in.
Moreover, user login and checkout are also broken. I can add products to the shopping cart as a guest and proceed to the checkout page, everything appears to be working, however when I put in registration details and press the checkout button, nothing happens (it is supposed to be redirecting to PayPal, as it does on my old host). I am using Journal 2 as my theme, which uses javascript to handle such buttons, so it shows no errors at all.
When I log in to my user account (as a customer) it only works for one page. If I move anywhere else on the website my account is getting logged out.
Based on the fact that I am unable to stay logged in my presumption is that the aforementioned issues have something to do with cookies.
Is there any way to resolve this?
I use OpenCart 2.3.0.2, and MariaDB 10.2.25-MariaDB-cll-lve - MariaDB Server (it differs from the initial host, which shows MySQL 5.6.45-cll-lve - MySQL Community Server (GPL)).
The error you get with alert:
SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
is from an ajax request that is made every-time you login / navigate inside the admin panel.
Steps to find the issue:
Before you login in the admin panel, right click in the browser and click "inspect element".
Choose tab "Network"
Login into the admin panel with your credentials.
Click ok at the alert of the error and then check into the network tab for the XHR (ajax) request made.
In the response sub-tab you will probably find a PHP exception. Find the cause of the error.
Important:
When a PHP error occurs while ajax request is made, the user token is "lost" so that's why you get logged out. It's not cookie related.
Hope the above helped you.
I get some video files from server and use in templates like this:
<div class="player-block" ng-if='hasSubscription(episode_detail.season)'>
<video ng-if='episode_detail' id="serial-video" class="video-js" controls preload="none" height="450" data-setup="{}">
<source ng-src="{{episode_detail.video_mp}}" type='video/mp4'>
<source ng-src="{{episode_detail.video}}" type='video/webm'>
<p class="vjs-no-js">
To view this video please enable JavaScript, and consider upgrading to a web browser that
supports HTML5 video
</p>
</video>
</div>
my nginx config:
Thats what i mean, try to rewind video in google chrome:
http://185.143.173.143:8000/media/SPONGEBOB_TRAP_REMIX_KRUSTY_KRAB_Vine_Remix.mp4
The result is not working in chrome rewind , I read that it is necessary to configure the server to return partial content.How do I configure nginx for this?
You have max_ranges set to 0, which will disable Range request handling in nginx. The simplest thing to do would be to remove that max_ranges 0 line. However, that still might not work if the origin (185.143.173.143) does not honor the Range requests.
In order to test if the origin (185.143.173.143) itself supports range requests, you will want to use curl from your nginx machine:
curl -I -r 0-100 http://185.143.173.143/path/to/video
If the Range request worked, the status will be something like 206 Partial Content and there will be a Content-Range header indicating the requested range. The Content-Length should be 101 in this case. If you get a 200 then likely your actual origin itself does not support range requests, and you will have to debug the configuration there.
I am having some trouble holding onto session when opening an initial new tab (target _blank) from IE11.
When I close all instances of IE11 and then open a fresh browser and navigate to the test webpage (default.aspx) the page stores a value in session and displays the session ID on the page. If I refresh the page the session ID stays the same. The page has a link to itself (default.aspx) with a target of _blank. If I click this link a new tab is opened, but the session ID is different. If I then refresh the original window the session ID now matches the new window.
<%# Page Language="C#" AutoEventWireup="true" Inherits="System.Web.UI.Page" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
</head>
<body>
<% Session["StoredValue"]="Test"; %>
<div>SessionID: <%=Session.SessionID%></div>
New Window
3rd Party Window
</body>
</html>
It appears this problem only occurs for the first window on the same domain opened in a new tab (I have verified the problem with both target="_blank" and by holding CTRL while clicking the link).
When I watch the cookie traffic with Fiddler I can see that the
session cookie is sent normally in the initial request from
default.aspx. When I click the link to open the page in a new tab
the session cookie is not being sent in the request headers.
If I restart the browser, go to the test page, open a new tab
manually and paste the link destination into it the cookie is sent
correctly in the request headers and the session from the new tab
matches the original tab as expected.
If I restart the browser, go to the test page, open google from a
link targeting _blank in the test page, and then click the link
opening the test page in a new tab the cookie is also sent correctly
in the request headers and the session from the new window matches
the original window as expected.
I believe this to be a client side issue but the site is running from Windows Server Standard 2008 R2 SP 1 in a 4.0 Integrated website with .NET 4.51 installed (also tried with only 4.5 installed).
The client is Windows 7 64-bit running IE11 (11.0.9600.16476). I have verified the problem on other machines running Windows 7 from IE11 and confirmed that it is not a problem in IE10 from Windows 8 in desktop mode. Everything works as expected in Chrome and Firefox.
I have verified the problem persists even if I:
Move security from Medium High to Medium
Disable Protected Mode
Change privacy to Accept all Cookies
Add the site to either the Local Intranet or Trusted Sites zone website list
Set a P3P compact privacy policy in the response headers stating no information is collected or used.
Set a P3P compact privacy policy in the response headers that would typically be accepted to allow 3rd party cookies within an iframe in past versions of IE.
Change the website ASP.NET session state settings to cookieless="UseCookies" or "false" or remove the attribute altogether (ASP.NET State Server).
Any ideas? Has anyone else seen this issue or similar?
This is an active bug according to microsoft. There is apparently no server-side way to fix this.
Link to bug report
Not a solution, but a clue:
We noticed similar behavior and tracked it down to requests to root/browserconfig.xml causing user to become unauthenticated. Server sent a new session cookie because Windows was not sending the existing one. Subsequent requests then sent the new session cookie value. We changed our server to look for this request and not set response cookies.
This is not a solution, but:
Try middle click instead. If that works for you 100% of the time(it did for me)
js: links with target='_blank' on ie remove defaultBehaviour and trigger middle click.
Problem solved.
Same issue coming for my login,But we tried it to resolve it by changing some setting in IE11 or other problematic browsers.
Goto tools=> Internet options=> Privacy
There click on Sites button. There add mydomain.com & click on Allow button.
Restart your browser.
This is my first question here, so please let me know if I have missed something or need to provide more information!
Key details:
C# 4.5
IIS 7.5 (Win 2008 R2)
Sitecore 6.6 rev 130529
I'm attempting to link Sitecore to the VS2012 LocalSTS instance provided by the Visual Studio Identity and Access Tool, following a blog post by Kevin Buckley (link) which was written before WIF was integrated into C# 4.5. I am attempting to perform passive RP behaviour.
I have updated the Microsoft.IdentityModel namespaces to System.IdentityModel and System.IdentityModel.Services namespaces as appropriate.
My <system.IdentityModel> section is as below:
<system.identityModel>
<identityConfiguration>
<audienceUris>
<add value="http://localhost/" />
</audienceUris>
<certificateValidation certificateValidationMode="None" />
<issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
<authority name="LocalSTS">
<keys>
<add thumbprint="9B74CB2F320F7AAFC156E1252270B1DC01EF40D0" />
</keys>
<validIssuers>
<add name="LocalSTS" />
</validIssuers>
</authority>
</issuerNameRegistry>
</identityConfiguration>
My <system.identityModel.services> is as below:
<system.identityModel.services>
<federationConfiguration>
<cookieHandler requireSsl="false" />
<wsFederation passiveRedirectEnabled="true"
issuer="http://localhost:14691/wsFederationSTS/Issue"
realm="http://localhost/"
reply="http://localhost/sitecore modules/fedauthenticator/sso"
requireHttps="false" />
</federationConfiguration>
</system.identityModel.services>
I have added the relevant modules (WSFederationAuthenticationModule, SessionAuthenticationModule) under <system.webServer><modules> :
<add type="Sitecore.Web.RewriteModule, Sitecore.Kernel"
name="SitecoreRewriteModule" />
<add type="Sitecore.Nexus.Web.HttpModule,Sitecore.Nexus"
name="SitecoreHttpModule" />
<add name="WSFederationAuthenticationModule"
type="System.IdentityModel.Services.WSFederationAuthenticationModule,
System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
preCondition="managedHandler" />
<add name="SessionAuthenticationModule"
type="FedAuthenticator.Authentication.WSSessionAuthenticationModule,
FedAuthenticator"
preCondition="managedHandler" />
The behaviour I am seeing is as follows:
User navigates to a page that is protected by Sitecore
WIF FAM module fires and at EndRequest, determines that a 401 status is returned
WIF FAM redirects to LocalSTS IdP as per settings (with appropriate querystring)
Javascript auto-submits form - I have disabled JS in browser for testing this but it works
LocalSTS page POSTs to URL specified in reply attribute with token information in the wresult field of the form
This is where the issue occurs. My understanding is that the FAM hooks the AuthenticateRequest event and then proceeds to detect the security token (via the presence and values of the wa and wresult form fields) and decodes the SSO token.
My issue is that this never occurs - I have enabled tracing and overridden the WSFederationAuthenticationModule to check, and although it correctly detects the event the first time and calls the CreateSignInRequest and RedirectToIdentityProvider steps, the subsequent POST to the site (containing the token) does not fire AuthenticateRequest and hence the FAM does not detect, create a cookie, or assign the correct IPrincipal to the request.
This leads to an endless loop where the request receives 401, is 302 redirected to the LocalSTS SSO page, which submits, POSTs to the Sitecore SSO page, which delivers a 401, etc etc.
Can anyone provide some insight into something I am missing, or anything else that might be hindering the FAM from detecting the POST request with token information in it?
Embarrassingly, to answer my own question - the reason this was occurring was that the response parameter was directing the SSO form POST to a URL that Sitecore responded to with a redirection to the NotFound page (ie the POST target was resolved by Sitecore to not exist).
As the NotFound page did not have any security, AuthenticateRequest was not firing.
I have yet to work out why the NotFound page was causing a redirect back to the SSO page - but at least now, once I corrected the incorrect value in the response configuration field, the token is being detected by the FAM and correctly processed for later modules (SAM, etc).
Edit - found the cause of the redirect loop
The redirect loop was caused by an erroneous setting in the web.config, which looked like below:
<authorization>
<deny users="?"/>
</authorization>
This meant that the token was posted to the NotFound page, which Sitecore apparently intercepts the request for and hence wasn't firing the FAM, therefore the user was not authenticated. This resulted in a 401 response code (due to the deny statement) that kicks off the SSO redirect - creating a loop.