I have a website that shows different content depending on the user country, but I faced an issue with Cloudflare enabled, which caches full page output and returns wrongly for other countries.
Tried to look into custom cache keys or some ways to cache pages by country but couldn't find the solution.
The feature you are looking for is Custom Cache Keys (available on the Enterprise plan). It allows you to include user features (such as country and language) in the key used to cache an object.
Related
I have a multi-tenant wagtail set up and we are currently working on getting up to date. We've just recently upgraded to v2.15 which introduced audit logging for all models instead of just page models.
AFAICT from looking through the wagtail code, the changes for a page model are only visible to superusers or admins with can_add_subpage or can_edit permissions which seems to effectively support multi-tenancy.
However, for all the other models there is no limitation put into effect. This means that an admin for Site A is seeing when changes are made to Site B or anytime a user is added or edited. We are using email addresses as usernames so this presents a rather major privacy issue.
This method hasn't been updated in any newer version, AFAICT, so I don't believe that just upgrading will fix this.
Does anyone have any ideas on either any wagtail settings we can change to keep Site and user changes invisible to non superusers or how we might localize BaseLogEntryManager.viewable_by_user so we can override the default wagtail implementation to our needs?
We have previously done something somewhat similar with the search available to admins by creating our own src/app/templates/wagtailadmin/pages/search.html and creating our own local version of https://github.com/wagtail/wagtail/blob/stable/2.13.x/wagtail/admin/views/pages/search.py
I had thought about trying to do something similar here however that doesn't seem like a good thing to do given how different those circumstances are and I think it was only possible using the register_admin_search_area hook.
I run a fairly large multitenanted Wagtail site. I have made public gist of the code we use in Wagtail 2.16 to restrict reports.
One of the main things we had to patch is the filters on the reports page. We do not want users on one site to even know there are other users in the system. This is implemented in the site_specific_get_users_for_filter method.
Although our non-page models all have site_ids, it was not possible to filter ModelLogEntries in site, so we settled for hiding that report from everyone except superusers.
Background Information
Content Search Web-Parts supports a caching feature as described here: https://support.office.com/en-us/article/Make-pages-load-faster-with-caching-in-the-Content-Search-Web-Part.
This should bring enhanced performance.
Problem
When configuring caching as described in the article the Content Search Web-Part does not return any results.
Steps to reproduce
Insert a Content Search Web-Part into a page
Edit the query (for testing purposes here: Recently changed items)
Under Settings activate the option caching for everyone except external users
After saving and publishing the Content Search Web-Part does not return any result. This is reproducable in multiple tenants.
Solution
If you want to enable caching for a security group, this security group requires permissions on the site collection (min. read permission).
In my case "Everyone, except external users" had no read permissions on the site collection.
Not sure if anyone is still using the legacy 1.4 - but I love it!
Background:
I have a user dashboard available at app.com/home/dashboard
To optimize DB hits, I cached the template Since the URL doesn't have a user parameter, a user ended up seeing another user's data
To beat this, I wrote a filter to include the user-id in the URL, giving each user their own URL like app.com/home/18/dashboard
While this prevents the data leak and provides the benefit of caching, it is messing reporting in GA, since I cannot track the total visits to the Dashboard (directly)
Has anyone worked around this?
I've had the same problem. To solve it I've decided to split the whole page into partials and components and cache those instead.
To make partials/component cached per-user just pass 'user_id' => $sf_user->getId() along with parameters. That will make user_id value used as part of cache entry key.
I've read all over the place and I'm trying to figure out if I am understanding the way caching happens in Drupal 6. We have a site that has a real time stock ticker in it. We have Drupal caching enabled so the stock price ends up getting cached and frozen at a specific spot. I figured a way I could handle it would be to put the ticker in a block I make in a custom module and set BLOCK_NO_CACHE, but if I'm understanding this correctly, if you have site caching enabled, then the ENTIRE page gets cached including any and all blocks on it regardless of their individual cache settings. Is this correct? So am I unable to take advantage of site caching then if I have certain spots that should not cache? Does anyone know of another solution I might be able to use to have the best of both worlds? To be able to have site caching, but also have a real time stock ticker? By the way, the stock ticker is making a JSON request to the Yahoo finance API to get the quote.
You are correct, the directive BLOCK_NO_CACHE is only applicable to block level. However when page caching is enabled then Drupal will cache the entire page (which includes the block as well). But this is only applicable to anonymous users. Drupal's philosophy is that the content for anonymous users is always the same so they get served the cached page. But this is not applicable to authenticated users. Since different users might have different access to certain parts of the page (e.g. the links block will look different for an admin than a regular user).
You might want to have a look at this discussion: BLOCK_NO_CACHE not working for anonymous users
And there is a solution, which you'll stumble upon this discussion. It's this module: Ajax Blocks. Extract from the module description:
Permits to load some blocks by additional AJAX request after loading
the whole cached page when the page is viewed by anonymous user. It is
suitable for sites which are mostly static, and the page caching for
anonymous users is a great benefit, but there are some pieces of
information that have to be dynamic.
Background:
Those of you who use FF3 may be familiar with an interesting new attribute of the address bar. It allows you to do sub-string auto-complete in order to filter through URLs that you have viewed previously.
Therefore, if you want to open the following URL:
http://longservernamehere.thatyou.nevercanremember.com/support/asdf1235234/kbid?1245
You can simply type any sub-strings of that URL that are sufficient to uniquely distinguish the URL:
long<space>never<space>support<ENTER>
This changes the way users can think about URLs, because now all they have to remember are the keywords (sub-strings) that will help narrow down the potential links
Problem: This feature is great, but there is a downside. Users have a decreased incentive to bookmark and memorize URLs. This obviously becomes a problem if a User needs to type in a URL at a remote site (for example during a sales call) and they fumble around because they cannot remember the URL of the snazzy product catalogue that they want to show during a meeting.
Obviously, there are ways around this problem: bookmark your urls and copy your bookmarks to your laptop before you go on a meeting; use a third-party solution or online bookmarking portal; social bookmarking sites and so on.
Question
The question is, for those users who do not want to use any of the above workarounds, is there actually a way to directly dig into the FF3 internals so I can write a script that will extract the components necessary to replicate a users auto-complete behavior on any machine?
Firefox stores all this information in SQLite databases. You can query it directly if you have SQLite installed. You can also browse it using the SQLite Manager Firefox plugin.
In summary, the url history is stored in moz_places, and the various "phrases" that you have typed in the address bar are associated with places via moz_inputhistory, which is a child table.
Their algorithm seems to be: as you type each character into the address bar, query moz_inputhistory for matching entries and display them in descending order by use_count.
Hope that helps.
EDIT: This site has a bunch of good information about the Firefox databases: firefoxforensic.com