We have a custom error page.
In production or staging you get the custom error page if you try to visit a non-existing page, e.g. /random_fhdjfhdjfhdj.html
I want to add a feature test to check the content of the custom error page but in development and test modes I get No route matches [GET] "/random_fhdjfhdjfhdj.html"
The error page template we use is in app/views/exceptions/error.html.haml
Adding config.consider_all_requests_local = false
in
environments/test.rb
fixed this.
fyi we already had
config.action_dispatch.show_exceptions = true
set
Related
In my staging environment (Shopware 6.4.17.2 with Varnish cache installed), I see an exception during register form submit.
ReCaptchaV3 is enabled
SHOPWARE_HTTP_CACHE_ENABLED=0
storefront->csrf->mode = twig
storefront->reverse_proxy->enabled = false
in this case I see no errors
ReCaptchaV3 is enabled
SHOPWARE_HTTP_CACHE_ENABLED=0
storefront->csrf->mode = ajax (correct setting for reverse proxy)
storefront->reverse_proxy->enabled = false
I see a call to
https://www.google.com/recaptcha/api2/reload?k=
And get invalid csrf token error, and no /csrf/generate call is sent.
Can you help me out?
Looks like your site key is missing from the request.
Look for an element with the class captcha-google-re-captcha-v3 in the source code of your page and see if the data-google-re-captcha-v3-options attribute of the element contains the siteKey.
If you can't find it in the source code, did you set your credentials in the administration at Settings > Basic Information > Captcha?
You can also set them via the CLI:
bin/console system:config:set core.basicInformation.activeCaptchasV2.googleReCaptchaV3.isActive true
bin/console system:config:set core.basicInformation.activeCaptchasV2.googleReCaptchaV3.config.siteKey xxxxxx
bin/console system:config:set core.basicInformation.activeCaptchasV2.googleReCaptchaV3.config.secretKey xxxxxx
I have a working Laravel project with loads of different routes.
I'm currently testing it and one of my tests was to check if a user were to use a delete or post route from the URL. I didn't know what the application would do honestly and it outputted the typical:
The GET method is not supported for this route. Supported methods: DELETE
which I have seen a million times. Is there a way to stop this error from coming up and instead output an error screen or simply redirect to a different view?
The error message:
The GET method is not supported for this route. Supported methods: DELETE.
should only appear when your Laravel site has APP_DEBUG set to true (in the .env file).
When APP_DEBUG is set to false as it should always be in on a live site, then the user will be shown a 404 error page instead.
You can easily test this by adding the following code to your routes file:
Route::delete('test', function() {
return 'You should never see this text when viewing url via a GET request';
});
May be u didn't noticed but ur form tag method attribute and route definition is different
I have set mode in .env file as: APP_DEBUG = false;
Now when error is happen it shows empty page with header: "Error".
How to make separated page for that?
You create a template in the views/error folder with name after the error code you want it to handle see https://laravel.com/docs/5.4/errors#custom-http-error-pages
You can create Blade templates for specific HTTP error codes in resources/views/errors/xxx.blade.php. For instance you can make resources/views/errors/500.blade.php for Internal Server Errors or resources/views/errors/404.blade.php for instances where a page can not be found. More here: https://laravel.com/docs/5.4/errors#custom-http-error-pages
I'm creating a SPA using vanilla JavaScript and currently setting up sw-precache to handle the caching of resources. The service worker is generated as part of a gulp build and installed successfully. When I navigate to the root url (http://127.0.0.1:8080/) whilst offline the app shell displays, illustrating that resources are indeed cached.
I'm now attempting to get the SW to handle internal routing without failing. When navigating to http://127.0.0.1:8080/dashboard_index whilst offline I get the message 'Site can't be reached'.
The app handles this routing on the client side via a series of event listeners on the users actions or, in the case of using the back button, the url. When accessing one of these urls, no calls to the server should be made. As such, the service worker should allow these links to 'fall through' to the client side code.
I've tried a few things and expected this Q/A to solve the problem. I've included the current state of the generate-service-worker gulp task, and with this setup I'd expect to be able to access /dashboard_index offine. Once this is working I can adapt the solution to cover other routes.
Any help much appreciated.
gulp.task('generate-service-worker', function(callback) {
var rootDir = './public';
swPrecache.write(path.join(rootDir, 'sw.js'), {
staticFileGlobs: [rootDir + '/*/*.{js,html,png,jpg,gif,svg}',
rootDir + '/*.{js,html,png,jpg,gif,json}'],
stripPrefix: rootDir,
navigateFallback: '/',
navigateFallbackWhitelist: [/\/dashboard_index/],
runtimeCaching: [{
urlPattern: /^http:\/\/127\.0\.0\.1\:8080/getAllData, // Req returns all data the app needs
handler: 'networkFirst'
}],
verbose: true
}, callback);
});
update
The code to the application can be found here.
Removing the option navigateFallbackWhitelist does not chage the result.
Navigating to /dashboard_index whilst offline prints the following to the console.
GET http://127.0.0.1:8080/dashboard_index net::ERR_CONNECTION_REFUSED
sw.js:1 An unknown error occurred when fetching the script.
http://127.0.0.1:8080/sw.js Failed to load resource: net::ERR_CONNECTION_REFUSED
The same An unknown error occurred when fetching the script. is also duplicated in the 'application > service workers' tab of chrome debug tools.
It's also noted that the runtimeCaching option is not caching the json response returned from that route.
For the record, in case anyone else runs into this, I believe this answer from the comments should address the issue:
Can you switch from navigateFallback: '/' to navigateFallback:
'/index.html'? You don't have an entry for '/' in your list of
precached resources, but you do have an entry for '/index.html'.
There's some logic in place to automatically treat '/' and
'/index.html' as being equivalent, but that doesn't apply to what
navigateFallback is doing...
We have a feature:
#smoke #acceptance
Scenario: Home page is available
When I visit the home page url
Then I expect no error code
With the final line implemented as:
Then(/^I expect no error code$/) do
expect(page.status_code).to eq 200
end
This sometimes fails. When debugging we've found the following:
the page itself always responds with 200
however, one resource within the page sometimes responds with 204
(which causes the test to fail)
This suggests that page.status_code does not equal the status code of the actual URL requested, but could be set to the status code of any (or presumably the last?) of the resources requested by the page.
Is this the correct explanation, and is it the expected behaviour of page.status_code?
Notes:
I realise that 204 could be construed as success, but this is not the
focus of this issue
status_code returns the result of the last request that triggered the phantomjs onLoadStarted callback - this should be the page, or potentially ajax requests initiated by the page -- it should not be assets being loaded directly as resources on the page (img, javascripts, css, etc). If it is a dependent asset then phantomjs has an issue and should be reported with reproducible example on that project. What type of request is reporting with a 204 response? If it's an ajax request then it is as expected - if not then its a bug in phantomjs. Note: checking response codes when using Capybara really is an anti-pattern, and you should generally stick to testing visible changes on the page.