I'm trying to style a custom login page for private pages in Wagtail, as per the docs.
If I follow the recommended method (for my app website) and place my template in 'website/password_required.html' (or website/templates/password_required.html), Wagtail does not pick up the new template. Instead it loads wagtailcore/login.html. I have tried several different locations for the customized template (including website/templates/website/. No location seems to catch it.
However, if I forego PASSWORD_REQUIRED_TEMPLATE and just directly override login.html with website/templates/wagtailcore/login.html, then it works. But I'd rather do this the right way than the way that just works.
I'm pretty sure that this is one of those situations where I've missed something small but crucial. I just can't figure out what it is.
Do not confuse the login page for private pages with Wagtail's main login page. The documentation is clear if you start out with this distinction in mind.
For private pages, a template specified by WAGTAIL_FRONTEND_LOGIN_TEMPLATE in the settings file is the correct method (and will provide a separate login page from the default).
Related
MDN docs state:
To enable a web page to contain an <img> element whose src attribute points to this image,
you could specify "web_accessible_resources" like this:
"web_accessible_resources": ["images/my-image.png"]
The file will then be available using a URL like:
moz-extension://<extension-UUID>/images/my-image.png"
<extension-UUID> is not your extension's ID.
It is randomly generated for every browser instance.
This prevents websites from fingerprinting a browser by examining
the extensions it has installed.
So, I would think that these resources cannot be read by any web page outside the extension, since they would need to know the random UUID.
However, the same MDN docs also state:
Note that if you make a page web-accessible, then any website may then link or redirect
to that page. The page should then treat any input (POST data, for examples)
as if it came from an untrusted source, just as a normal web page should.
I don't understand how "any website may then link or redirect to that page". Wouldn't it need to know the random UUID? How else could a webpage access this resource?
The point of Web Accessible Resources is to be able to include them in a web context.
While you can communicate the random UUID to the webpage so that it can use the file, it doesn't have to be included by the website code itself. Here's a hypothetical scenario:
You're writing an extension that adds a button to evil.com site's UI. That button is supposed to have an image on it.
You bundle the image with your extension, but to add it as src or CSS property to the webpage you need to be able to reference it from a web context.
So, you make it web-accessible, and then inject your UI element with a content script.
Perfectly plausible scenario.
Note that a random third-party site villains-united.com can't just scrape the URL to know if your extension is installed, since the URL is per-browser unique. This is the intent behind WebExtensions's UUID over Chrome's extension-id model.
However, let's continue our hypothetical scenario, from a security perspective.
The operators of evil.com are unhappy with your extra UI. They add a script to their code that looks for added buttons.
That script can see the DOM properties of the button, including the address of the image. Now evil.com's code can see your UUID.
Being the good guy, your extension's source code is available somewhere, including the page that launches nuclear missiles if called (why you would have that and why it would be web-accessible is another matter, perhaps to provide the functionality to good-guys-last-resort.org).
evil.com's script now can reconstruct the URL of this trigger page and XHR it, plunging the planet into nuclear apocalypse. Oops. You probably should've checked the origin of that request.
Basically, if a web-accessible resource is used in a page, the UUID likely leaks to that page's context via DOM. That may not be a page you control.
To run analytics javascript on every salesforce page I want to insert Javascript in every page.
So far I read about a couple of different methods:
home page component
a HTML Home page component (need to customize UI to show the components on every page)
limitations: does not work for Chatter, Reports and Setup
possible issue: these comments indicate problems with 'winter 13'
Custom Button with Javascript
(don't know much about this yet) sound like one has to create/assign the buttons to object-types)
Custom APEX controller?
How would this work?
Visualforce page ??
How would this work?
To my understanding it would be possible to replace everything with visualforce pages, but this is obviously not very elegant/maintainable.
I'm curious to see what other methods there are, in partciular by modifying the controller?
What other things to consider (downsides, risks) with the presented methods?
Sidebar component sounds best suited for that to be honest.
Any button/link you'll add to object detail pages will both require clicking on it(!) and won't work on "tab view", "new record" or "edit" pages. You could override most of them with VF pages but that's A LOT of work and there's no way you'll be able to customize UI of these special places: Chatter, Console tab, Reports,Dashboard.
I'm not sure what do you mean by "modifying the controller", there's no such global thing you'd have access to.
There's option of embedding a small VF page into page layout of every detail page but it's equally limited in terms of maintenance and not being present on the new/edit pages.
There are better analytics options for Force.com Sites (not the least of them being the <site:googleAnalyticsTracking/> tag). You should also receive a monthly newsletter (typically with 2-3 month's delay) summarizing usage of your Salesforce instance, user adoption, areas to explore etc. If you don't - check your User's "receive salesforce newsletter" etc settings.
I want to add new section to the leads to call api request depending on the lead website url
It's something like creating the web-based tab, but I want to ad inside the leads to get data from a website depending on the lead website url
You can have VisualForce pages inline in a page layout, but the height is fixed and I generally don't find it to be an elegant solution, but it may work well in your case depending on what information you're bringing back and whether the length needs to be dynamic.
I'd implement this as a Visualforce page, and then use a formula field on the link to create a link to the page based on the Lead's URL. Users could then click this link to popup a new window with your page and information.
This might not be possible but I thought I'd check with everyone.
Is it possible to load a WebBrowserTask on WP7 but to have the url entry box collapsed? I'd also like to set IsHitVisble to false?
The reason I want to do this is to load a url (through databinding) but ensure that the user can't browse to other links on the page. I also need to keep the phones share control in the tool bar so I can't just use a webbrowser control and set the source to the url.
Does anyone have any ideas?
Not possible. You can use a WebBrowserControl inside your own app, but it's not recommended.
Basically such odd/weird limitations as this, don't belong in any modern day craftsmanship. And thus why it isn't a possibility (thanks Microsoft!)
I want to have two separate interfaces to my website, one that is silverlight, and one that is normal html for people who don't have Silverlight, and for search engines. They would have exactly the same content, the Silverlight one would just be a richer experience.
If someone with Silverlight copies the URL to a certain page, it will have a '#' in it (app#page1). If they then want to link to that page on their blog or something, it will have the # in it, and a search engine probably wouldn't consider it as a separate page from app#page2.
Is there any way to make the navigation from within Silverlight update the URL with a '/' instead of a '#', without actually loading a separate page? This way the URLs in the address bar appear like a normal websites' URLs ('app/page1', 'app/page2').
Is there any way to make the navigation from within Silverlight update the URL with a '/' instead of a '#', without actually loading a separate page? This way the URLs in the address bar appear like a normal websites' URLs ('app/page1', 'app/page2').
Unfortunately, no. The reason that Silverlight navigation URLs use # is that you can move around within a page by moving to an anchor location. If you used a full URL with '/' separators, it would cause the browser to navigate to a new page, which would reload your Silverlight application. This would basically unload your Silverlight application, and load a new one with the new URL.
The reason they use the # sign is because this is interpreted by the browser as moving to a location in the page, otherwise would reload the page.
As far as search engine implications I'm not sure either way. Maybe someone more experienced with SEO can chime in on that.
However I'm sure you can get the behavior you're looking for, just may take some trickiness on your end. Another way pass information to the Silverlight client runtime is using Query String parameters. You can access query string params using the System.Windows.Browser.HtmlPage.Document.QueryString collection, you could then load the Page or User control with the content you desire based on that parameter.
As far as mimicking a folder structure using '/'s. I know there are ways to do this using custom web server settings / HTTPModules. I assume you're using IIS/ASP.Net, I would look into this from Guthrie:
http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx
Takes a bit of hackery, but if you're really set on doing it I'm sure you could. You will also face the things the above poster mentioned, if you attempt to do use the same logic during a session. This may work though for just the deep linking aspect you're looking for.