I want to improve the web speed with Cloudflare (Pro plan), and I have the following options already selected in the Speed and Caching sections of my Dashboard:
- Autominify (JavaScript, CSS, and HTML, selected)
- Brotli: On
- Enhanced HTTP/2 Prioritization: On
- Mirage: On
- Caching Level: Standard
- Browser Cache Expiration: 1 month
- Always Online: On
- Development Mode: Off
I wondered if, after having selected all these options, now I must set the Page Rules for every pages (for instance, for '* mydomain.com/ *'), or it's already activated.
Thank you very much.
Those speed features are domain-wide settings, which will be effective for all web assets within your domain. Therefore, you will not need to use page rules on them any further. Unless you want to set fine-grained control to overwrite the domain-wide settings, for example disable auto-minify, cache-level, mirage etc for certain URI path, you can do so using page rules.
Related
We've got a very large Web application with about 1000 pages to be tested (www.project-open.com, a project + finance management application for service companies). Each page may take multiple parameters (object-id, filters, column name to use for sorting, ...). We are now going to implement additional security checks on these parameters, so we need to systematically test that a) offensive parameter values are rejected and b) that the parameter values actually used by the application are accepted correctly.
Example: We might want to say that the sort_column parameter in a page should only consist of alphanumeric characters. But the application in reality may include a column name with a space in it, leading to a false positive security alert (space character not being an alphanumeric character).
My idea for testing this would be to 1) manually navigate to each of these pages in proxy mode, 2) tell ZAP to start spidering all links on this page for one or two levels and 3) tell ZAP to start fuzzing on these URLs.
How can this be implemented? I've got a basic understanding of ZAP and did some security testing of ]project-open[. I've read about a ZAP extension for scanning a list of URLs, but in our case we want to execute some specific ZAP actions on each of these URLs...
I'll summarise some of your options:
I'd start by using the ZAP desktop so that you can control it and see exactly what effect it has. You can launch a browser, explore you app and then active scan the urls you've found. The standard spider will find explore traditional apps very effectively but apps that make a lot of use of JavaScript will probably require the ajax spider.
You can also use the 'attack mode' which attacks everything that is in scope (which you define) that you proxy through ZAP. That just means the ZAP effectively just follows what you do and attacks anything new. If you dont explore part of your app then ZAP wont attack it.
If you want to implement your own tests then I'd have a look at creating scripted active scan rules. We can help you with those but I'd just start with exploring your app and running the default rules for now.
Ive made a minor text change to our website, the change is minor in that its a couple of words, but the meaning is quite significant.
I want all users (both new and returning) to the site to see the new text rather than any cached versions, is there a way i can force a user (new or returning) to re download the page, rather than fetch it from their browser cache ?
The site is a static html site hosted on a LAMP server.
This depends totally on how your webserver has caching set up but, in short, if it's already cached then you cannot force a download again until the cache expires. So you'll need to look at your cache headers in your browsers developer tools to see how long it's been set for.
Caching gives huge performance benefits and, in my opinion, really should be used. However that does mean you've a difficulty in forcing a refresh as you've discovered.
In case you're interested in how to handle this in the future, there are various cache busting methods, all of which basically involve changing the URL to fool the browser into thinking its a different resource and forcing the download.
For example you can add a version number to a resource so you ask for so instead of requesting index.html the browser asks for index2.html, but that could mean renaming the file and all references to it each time.
You can also set up rewrites in Apache using regular expressions so that index[0-9]*.html actually loads index.html so you don't need multiple copies of the file but can refer to it as index2.html or index3.html or even index5274.html and Apache will always serve the contents of index.html.
These methods, though a little complicated to maintain unless you have an automated build process, work very well for resources that users don't see. For example css style sheets or JavaScript.
Cache busting techniques work less well for HTML pages themselves for a number of reasons: 1) they create unfriendly urls, 2) they cannot be used for default files where the file name itself is not specified (e.g. the home page) and 3) without changing the source page, your browser can't pick up the new URLs. For this reason some sites turn off caching for the HTML pages, so they are always reloaded.
Personally I think not caching HTML pages is a lost opportunity. For example visitors often visit a site's home page, and then try a few pages, going back to the home page in between. If you have no caching then the pages will be reloaded each time despite the fact it's likely not to have changed in between. So I prefer to have a short expiry and just live with the fact I can't force a refresh during that time.
I use imagegen.ashx to resize images on my Umbraco 4.7 website. It is by default disallowed in robots.txt and images for which I use the handler do not appear in search engines results - I have checked in Google Webmaster that they are blocked. I would like to allow this images to be searched.
Can I achieve this by allowing the imagegen.ashx in robots.txt?
I also would like to know is there any good reason why it is disallowed by default?
And if I make it allowed would it resolve my problem with blocked images or it requires some more configuration changes?
You can safely remove imagegen.ashx from the robots.txt.
So far I know it is not default disallowed in robots.txt Umbraco and ImageGen do not create default a robots.txt (not in recent ImageGen versions)
Images generated with Umbraco and ImageGen can just be found and displayed in Google. There is no risk,
ImageGen has some low risks, An attacker can changing the query string parameter and so repeatedly generate a new unique image, (disk space, cpu cycles) but the image size is limited in the config. and this is independent of the robots.txt
I use boost module and now I want to use captcha to prevent spam comments. These two module works with each other successfuly?
Unfortunately, the CAPTCHA module disables Drupal page caching. And as Boost provides static page caching for increasing performance, these two modules will not work correctly together. So what are the options to prevent spam while using page caching? There are several ways to solve this problem:
Use CAPTCHA and make comments on a separate form. In order to do this make the following steps:
1) go to admin/content/types
2) Click the edit link for the page, blog entry, or other type you want to modify
3) In the Comment Settings find “Location of Comment Submission Form”
4) Select the "Display on separate page" option and save content type.
You can do this with each content type which is displayed often enough to decrease performance.
2. Use Mollom which is a great solution for all spam problems and make sure it is set in the following way:
Protection mode: Text analysis
When text analysis identifies spam: Automatically discard the post.
Also, see other alternatives to CAPTCHA module for spam prevention on Drupal websites here.
3. Use Boost Captcha which is a new module allowing boost caching of Drupal pages with forms with CAPTCHA.
I'm looking for the best URL schema to use for a web app that has multiple versions, namely several languages and a simplified version for use by mobile phones - both aspects can be combined, so there's an English regular and mobile version, a German regular and mobile version, etc.
Goals (in order of importance):
User-friendliness
Search engine friendliness
Ease of development
Aspects to consider:
How should the URLs look like?
How should the user navigate between versions?
How much logic should there be to automatically decide on a version?
I'll describe my concept so far below, maybe some of you have better ideas.
My current concept:
When a new user arrives, the app decides, based on cookies (see below), the Accept-Language: header and the user agent string (used to identify mobile browsers) which version to show, but does not reflect this in the URL (no redirects)
It defaults to the non-simplified English version
There are prominently displayed icons (flags, a stylized mobile phone) to choose other versions
When the user explicitly chooses a different version, this is reflected both in a changed URL and a browser cookie
The URL schema is / for the "automatic" version, /en/, /de/, etc. for the language version, /mobile/ for the simplified version, /normal/ for the non-simplified one, and combinations thereof i.e. /mobile/en/ and /normal/de/
mod_rewrite is used to strip these URL prefixes and convert them to GET parameters for the app to parse
robots.txt disallows /mobile/ and /normal/
Advantages:
The different language versions are all indexed separately by search engines
Cookies help, but are not necessary
There'S a good chance that people will see the version that's ideal for them without having to make any choice
The user can always explicitly choose which version he wants (this makes the /normal/ URL necessary)
Each version has an URL which will display exactly that version when passed to others
/mobile/ and /normal/ are ignored by search engines; they would only be duplicate content.
Disadvantages:
Requires heavy use of mod_rewrite, which I find rather cryptic
Users could send their current URL to someone and that person, when visiting it, could end up seeing a different version, which could cause confusion
There is still duplicate content between / and /en/ - I can't disallow / in robots.txt - should I trust the search engines not to penalize me for exact duplicate content on the same domain, or disallow /en/ and accept that people coming to / via a search engine may see a different version than what they found in the search engine?
I suggest subdomains, personally.
I wouldn't include the mobile at all - use the useragent to determine this, and possibly a cookie incase the user wants to view the full site on their mobile (think how Flickr and Google do it). But for languages, yes - primary language at http://mydomain.com/, secondary languages at i.e. http://de.mydomain.com/ or http://fr.mydomain.com/
I am unclear why you would want to incorporate any kind of what you call versioning information, such as accept-language or user-agent, specific designation in the URL scheme. The URL scheme should be indicative of the content only. The server should investigate the various request headers to determine how to retrieve and/or format the response.