I am wondering why sencha production build not working in live server. I already tested the production build in my local then I upload it in my web server. It shows me 2 alert box.
Requested: http://www.simplicity-gaming.net/mobile/resources/css/app.css with checksum: ac90c164209648c5e1b9e7c1569874b93174de3f but received: dy,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,hinstead. Attempt to refresh the application?
Requested: http://www.simplicity-gaming.net/mobile/app.js with checksum: a159722373bb74a92d7f865503ea9b07faa9277c but received: unction(){var global=this,objectPrototinstead. Attempt to refresh the application?
Here is my URL
http://www.simplicity-gaming.net/mobile
PROBLEM SOLVED.
My webhost has Cloudflare and it has html and js minifier enabled. Disabling it solved my problem.
Are the checksums in tact? Try viewing the source and verify if the server is not removing the comment
Related
I have tested successfully a debug version of an instant app that is called by an app link, e.g., https://domain/?q=1234567. I have created a release version and signed it with a "Create new" key. Upload to a new Closed Testing release fails, however, because the Bundle is signed "with the wrong key".
What am I doing wrong in trying to test a release version without Publishing publicly? Do I have to go forward to Publish and rely on my previous debug testing of the app link or is there a way to verify the app link operation in closed testing?"
It took a lot of digging, but I found the answer here:
https://developer.android.com/studio/run/rundebugconfig
It is the documentation for "Create and edit run/debug configurations".
It says:
URL - Launch a URL that matches an intent filter in your app's
manifest. When selected, the URL field appears below, where you can
enter the URL.
You must fill in this field to launch an Android Instant App. You may
also use this to test your Android App Links.
This confirms that my successful testing of my app link to initiate my instant app proves it will work in release form when it is published.
I have a VueJS application that is deployed to a local IIS 10 server for intranet use.
Trouble is, the index.html file is getting cached and a forced, manual clearing of the browser is needed to see updates. I understand there are ways on the server side to prevent this, but I'm unclear based on what I've read so far as to what the proper way of making sure the html file isn't cached is (js, css and the like are, of course, not cached since they have the additional value appended to the file name during build.)
I'm very much a novice when it comes to the server side of things, so any insight would be greatly appreciated. Thanks!
Which packaging tool do you use in your project? Generally speaking, Webpack/Vue-CLI has settings for prevent the file from caching in the browser on the client-side. In other words, it adds hash value to output files which could flag the version we build recently, this will result in the client browser to forcibly request the new version file.
In the Webpack.config.js
output: {
filename: '[name].[contenthash].bundle.js'
}
https://webpack.js.org/guides/caching/
See these links for more details.
Browser cache problems with webpack chunks and vue.js components
how to force clearing cache in chrome when release new Vue app version
VueJS/browser caching production builds
I ran two sample Blazor WebAssembly apps accidentally on same port at https://localhost:44381, then things are messed up. One of the apps is erroring out because it tried and failed to load DLLs from the other sample app. I tried going to browser's devtool Application > Clear storage, but no help. How do I totally clean out the DLLs of a Blazor WebAssembly app from browser so that I could start fresh again?
Blazor WASM applications from version 3.1 download a file blazor.boot.json which lists the assemblies along with a sha256 hash to indicate the version. These assemblies are now downloaded to the browser's Application Cache Storage (see example below).
Application -> Clear storage should work - check that Application cache is selected on the Application -> Clear storage page:
Using the Empty Cache and Hard Reload will not clear out this cache, but will reload the blazor.boot.json file, and if the cached files have changed (the hash is different) then they should be reloaded.
You can also clear out individual assemblies from the Cache Storage view - right-click and you can delete them. When you refresh the application, Blazor will download the latest version.
Chrome and the new Edge press F12. This opens the developer tools. Whilst this is open right click the refresh page Icon on the browser. On that menu choose empty cache and hard refresh. This is the only way to clear everything including icons and PWA settings.
Just press Ctrl+F5 it cleans cache and gets files again.
In your .csproj (for your wasm site) file you can force the app to download resources each time it's requested. Bit of a performance hit for the first load, but gets you over the current problem.
<PropertyGroup>
<BlazorCacheBootResources>false</BlazorCacheBootResources>
</PropertyGroup>
There are some caveats - see documentation here: https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-5.0#disable-integrity-checking-for-non-pwa-apps-1
I'm working on 2 projects and installed Angular 8 in my machine for new project. But, I'm using Angular 5 for existing project. I'm getting 431 Request Header Fields Too Large error in my Angular5 project after I installed Angular 8. How can I fix this error in my current project?
Thanks
I've had the same problem and it looks like that is a browser cache issue. Try to open your application in an incognito windows or clean your cache, i did it and it worked
To add to Murilo's answer, you can clear the guilty cookie in chrome by:
hitting F12 (to open developer tools)
in the application tab expand cookies, right click the localhost url.
click clear.
I've had the same problem, after checked i found content of HttpHeaders too large
During App Authenticity testing in MobileFirst 8.0, I found a strange behavior in switching between enable and disable of App Authenticity setting on Console, using an (Android) app's debug package and release package:
Followed the instruction of signing the app (release package) with mfp-app-authenticity-tool.jar tool, registered .authenticity_data file via Console, and set Security-Check Configurations of the app to use appAuthenticity setting with Expiration Period value.
(For initial connection) After installing the release version of the app on a device, the app successfully connects to MFF Server and calls an adapter.
(After removing the release version of the app from the same device) Installed debug version of the app on the device, and the app fails to connect to MFF Server, as expected.
Disabled App Authenticity by deleting Authenticity File on Console, the debug version of the app on the device successfully connects to MFF Server and calls an adapter.
"Re-enabled" App Authenticity with same instructions as the first step, but the debug version of the app still can connect to MFF Server and calls an adapter. I understand that there's Maximum Token-Expiration Period and Expiration Period setting, but I set both value to 60 seconds for just testing. (Reinstalling the debug version of the app and testing the action without changing on Server gives an expected behavior - i.e. not able to connect.)
I'm wondering if this is normal behavior of enabling / disabling App Authenticity setting in real-time on Console.. and if the feature is designed for just one set of actions of Enable -> Disable only.
Any thought?
Thanks!
By default, App Authenticity is only being checked during the client registration process. Which means that the next time you connect to the server, it will not be checked.
In order to run App Authenticity on every token request, add appAuthenticity to the Mandatory scope section on your application in the console. Then set the expirationSec to 60 seconds for example.
The tutorial was adjusted to clarify this: https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/authentication-and-security/application-authenticity/#configuring-application-authenticity