While running SvelteKit app on CloudFlare Pages, it loads on the first request. When the page is refreshed then it throws an error.
We are using axios in the load() function on Sveltekit to fetch data.
The error in Cloudflare logs is adapter http is not available in build
It works perfectly on Vercel.
Tried to change ENV loading strategy, Host on other platform.
Using fetch instead of axios solved the error.
Related
TL:DR - How can I get the Azure Application Gateway to pass 5.xx errors from the App Service to my browser? Currently the Application Gateway swallows any 5.xx error generated by the App Service and delivers a "502 - Web server received an invalid response while acting as a gateway or proxy server" error. I want to see the underlying error. And, I guess have the Application Gateway ignore the error and just pass everything directly through from the App Service to my browser.
I've turned on Application Logging for the App Service. I can see some 5.xx errors in the LogFiles/DetailedErrors folder. But I think I'm missing some understanding of what Kentico does when it throws a 5.xx error. Normally if you're on a normal server or locally, you don't see the generic 503 page as your browser is redirected to the 'Invalid license key' page.
I don't know what sort of internal (black) magic Kentico does to deliver this page, rather than the normal asp.net 503 Service Unavailable page. But this page is very useful to see, as it gives an idea of what's really wrong with the Kentico configuration.
Background:
Kentico seems to use some 5.xx errors for information. eg, the licence check throws a 503 error, instead of a useful 200 status with a message that you need to check your license.
We have a MVC Kentico 11 MVC site. It hosts multiple websites. We are trying to set up an Azure Application Gateway that points to two App Services, one MVC, one for Kentico admin.
So far I have the Kentico admin working properly - multiple domains can all access the CMSDesk via the Application Gateway. However, the MVC site is problematic. I can only get the default domain for the App Service to work. All other domains show a 502 error.
I'm thinking that the 'default' domain of the App Service works properly because the Application Gateway isn't forwarding the domain properly to the App Service, but I don't know how to verify this. And it's just my latest theory, and it's pretty shaky - if I remove the app, and just put static .htm files there, I can browse to them without error.
It seems that the "502 - Web server received an invalid response while acting as a gateway or proxy server" message is served up by the Application Gateway for any 5.xx error generated by the App Service, essentially hiding details of any Server Errors issues that may arise. eg: The Kentico license error generates a 503 that is preseneted as a problem with this module: "PageHandlerFactory-Integrated-4.0", rather than the obvious 'invalid license' screen that you normally see when Kentico is hosted on a normal server.
The Invalid license error will only show for the Admin site, not the MVC site. Never looked into what happens when that error is displayed, just always go in and add my missing license. If you want to get the full error, I would make sure you are logging all errors in your MVC into the Event log in Kentico.
In your Global.asax.cs file, you can probably do something like this:
public void Application_Error(Object sender, EventArgs e)
{
Exception exception = Server.GetLastError();
EventLogProvider.LogException("MVC", "EXCEPTION", exception);
}
Then you should be able to see the error in the Admin Event log.
This post may help with capturing errors in MVC better. I did something like this answer for displaying errors on the MVC site.
As soon as the Application Gateway detects a backend as unhealthy, you'll see the 502 error.
You can adjust the Health probe in your Application Gateway, so that the probe matching conditions include code 503. For example, set the condition to 200-503.
After you've done that, you should see the 503 page from Kentico.
I have the following issue.
After upgrading an application to ASP.NET 2.0 I get a 400 (bad request) status response whenever trying to authenticate in production.
This error does not reproduce locally and doesn't reproduce when using the production container locally.
The only difference that exists between production and local is that there is a reverse proxy in production that implements SSL for all requests.
I've tried moving the authentication code from middleware (as it was initially implemented) into a controller and I've changed the path to the route that was used for authentication. I still get the error.
All other requests work fine (provided you have a jwt token attached to them).
I should also mention that the CORS headers aren't set on the 400 response.
Any ideas?
This issue was caused by an upstream reverse proxy that was stripping some headers from the requests. Requests with verbs Post & Put were affected.
Set the log level of your application to Information to see what Kestrel is actually complaining about.
In our case we had to switch hosting providers because of the issue.
I have an Azure mobile app authenticating on azure with FB and Twitter. I am able to login to both but when testing web api calls locally (hosted in IIS) - any controller with the Authorize attribute - returns a 401.
The alternateLoginHost is set to the Azure host and it is providing me with a token after a successful login.
I followed the instructions in the docs about setting up Local debugging with authentication.
It is using attribute based routing - config.MapHttpAttributeRoutes()
Here is my full OWIN startup class
public class OwinStartup
{
public void Configuration(IAppBuilder app)
{
HttpConfiguration config = new HttpConfiguration();
config.MapHttpAttributeRoutes();
new MobileAppConfiguration()
.ApplyTo(config);
app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()
{
SigningKey = ConfigurationManager.AppSettings["authSigningKey"],
ValidAudiences = new[] { ConfigurationManager.AppSettings["authAudience"] },
ValidIssuers = new[] { ConfigurationManager.AppSettings["authIssuer"] },
TokenHandler = config.GetAppServiceTokenHandler()
});
app.UseWebApi(config);
}
I have seen references in the documentation about either using the global http config passed in from asp.net or creating a new one - I tried referencing the GlobalConfiguration.Configuration instead of creating a new instance but it didn't help.
Is there a way to hook into the OWIN pipeline to see if the token is making it to the app service authentication module?
[EDIT] ZUMO AUTH HEADER
I am also adding the x-zumo-auth header and setting it's value to the token from the current user like this
request.headers.append('X-ZUMO-AUTH',
app.azureClient.currentUser.mobileServiceAuthenticationToken)
And I can see it in each request being made to the api. A call to the endpoint https://mysite.azurewebsites.net/.auth/me using this mechanism is returning a correct response so I know the token is valid.
[EDIT] Verified working in Azure after adding ZUMO Version Header
deployed the web api to azure and tried to call my web api endpoint and received a bad request error. It turns out it required an additional header for the version
'ZUMO-API-VERSION', '2.0.0'
I added the header and it worked.
Tried the local call again with the version header but still getting 401.
All I can assume is the OWIN middleware is not receiving the token probably due to a config problem - need some transparency into the pipeline to test some of these theories - not sure the best way to do that
Not sure where to look next in solving this.
[EDIT] OWIN Pipeline Authenticate stage Hook
OK - figured how to set up the equivalent to asp.net pipeline event handlers in OWIN - in my startup file I added this code to execute when the Authenticate stage is reached
app.Use((context, next) =>
{
return next.Invoke();
});
app.UseStageMarker(PipelineStage.Authenticate);
Added a breakpoint and when the debugger stops I can see that in the call stack
that the Azure App Service Middleware in in the pipeline
Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware
<Microsoft.Azure.Mobile.Server.Authentication.AppServiceAuthenticationOptions>
.Invoke(Microsoft.Owin.IOwinContext context)
Confirmed OWINContext.Request.Headers Contains the Correct Auth Token
Looking in the debugger the token is indeed in the Context.Request.Headers collection at the Authenticate stage of the OWIN pipeline and it has the correct value. For some reason still receiving the 401 status
I doubly checked the value I am using for the SigningKey - copied from the WEBSITE_AUTH_SIGNING_KEY value in Azure.
[EDIT] Debugging with source and exception being thrown in ValidateIdentity
AppServiceAuthenticationHandler.ValidateIdentity
Downloaded source v1.1.157.1, loaded symbols from symbolsource but those are marked as 1.0.157.1 and visual studio is complaining that the source is different than when the module was built. Because of this I cannot step through the code to see the exception that is being caught.
[EDIT]Built and Referenced v1.1.157.1 DLL - exception type now visible
In the ValidateIdentity method when it calls
options.TokenHandler.TryValidateLoginToken
The following exception is thrown
"Could not load type 'System.IdentityModel.Tokens.JwtSecurityToken'
from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.0.0.127,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'."
[EDIT] Finally found and fixed the issue
There was an issue posted on GitHub for IdentityServer having to do with a breaking change with a nuget package - going from v4 -> v5 of System.IdentityModel.TokensJwt package.
https://github.com/IdentityServer/IdentityServer3/issues/3017
I downgraded my install to v4.0.x and it fixed the exception and also fixed the 401 errors I was seeing when running locally.
All is good now
Do you have the correct app settings for authSigningKey, authAudience, and authIssuer in your web.config?
FYI -- a good writeup of the setup is here in case you haven't stumbled upon it yet: http://www.systemsabuse.com/2015/12/04/local-debugging-with-user-authentication-of-an-azure-mobile-app-service/
Is your localhost serving https traffic?
If a controller is decorated with [Authorize] it will require that the request/response occurs over https.
If you're targeting http://localhost, [Authorize] will cause a 302 to https://localhost.
This 302 can break the auth process. The solution would be to serve https locally, point your client to the appropriate port (my box uses :44300), and try it out again.
Also, make sure any relevant redirect URLs go to the https:// version of the URLs you're using.
After going through walkthroughs I had a test mvc app, test web api, and identityserver3 all working perfectly on my machine. I deployed IdentityServer3 to our servers in AWS behind a load balancer. I followed all the instructions in the Deployment wiki. I am able to hit the .wellknown configuration fine after deployment from a browser on my machine.
I changed the authority url for the mvc and api test apps to point to the aws deployment. Clients, Scopes, users, etc are all configured identically as they are hitting the same database as it was when running on local machine.
I can get an access token using RequestResourceOwnerPasswordAsync just fine so I think ids is installed fine.
However, both the API and the MVC app just trying to use implicit flow are now failing. FOr instance, when I try to hit a mvc controller action marked with [Authorize] I get an error stating "An invalid request URI was provided. The request URI must either be an absolute URI or BaseAddress must be set".
If I try to hit the webapi from the mvc app (both running locally on my machine) after a successful RequestResourceOwnerPasswordAsync call, I get the error "Response status code does not indicate success: 401 (Unauthorized)." after what seems like a timeout.
Any help would be greatly appreciated.
Figured out the problem. When specifying PublicOrigin, it has to be a full URL and not just the domain. I had left off https:// prefix.
The web api issue was related to connectivity to the identity server. There was some incorrect proxy settings for the app.
I'm using the extended accounts package 'accounts-facebook'. When I run my application locally, the login authentication procedure works after adding 'http://localhost:3000/_oauth/facebook?close' under Valid OAuth redirect URIs.
After deploying the application however, the login pop-up gives no error, but remains blank without completing the authentication procedure. I've tried adding 'http://www.algoloom.com/_oauth/facebook?close' and loads of possible variations to this, as some other forum discussions suggest, but the login procedure is never completed.
While I was testing my application in its deployed version, I managed to get Facebook login working by changing its ROOT_URL to 'http://www.algoloom.com:3010', in combination with 'http://www.algoloom.com:3010/_oauth/facebook?close' as a redirect URI. Now that I've set nginx to redirect to port 3010 by default, the 3010 disappears from the main website URL. As a result I've also set my ROOT_URL to 'http://www.algoloom.com'. This works fine for any other website functionality, but I can't seem to fix my my issues with Facebook login.
Any ideas on how to solve this?