We have a legacy JSF application running on jetty. It has pages like /foo/bar/mypage.xhtml with outputLink tags like: <h:outputLink value="?param1=value1">Click</h:outputLink>. These links are being generated without any context, and so when clicked, the browser correctly links to the current page with the specified parameters.
We recently installed Xebia's XForwardedFilter to fix issues with running the app behind a proxy. With it enabled, though, the link is getting generated by jsf with the context (which from my understanding is the correct behavior). Unfortunately, the context doesn't include anything after the last /, so the current page is not included in the link. For the example above, the link becomes /foo/bar/?param1=value1 instead of the desired /foo/bar/mypage.jsf?param1=value1
The workaround is to include the current page for the link value: <h:outputLink value="mypage.jsf?param1=value1">Click</h:outputLink>. The problem is that there are a lot of these links in the application and some of them are in includes which will require passing an additional parameter to indicate the page that should be referenced.
Is there a way to get the outputLink to generate the full context? Alternatively, if we could disable the context generation altogether so that the prior behavior occurs, that would work as well.
Related
We are experiencing some odd behaviour when attempting to POST to the Lost Password action on the Account Controller in Orchard.Users.
The important details
We are not directly using Orchard source code, we are using a compiled re-distributable and building modules that are deployed to the redist host, so direct debugging is a challenge.
We have tried this with the vanilla Orchard 1.8.1 (the version of our redist) so we can all but eliminate any of our module's code.
When POSTing the form we get back a 302 Moved response with the Location Header set to /. This then does end up to root rather than to the Success page or back to the Enter New Details password. The user's password is not successfully changed.
Looking at the Account Controller in source shows that the only result that expressly returns the root is when the the call IUserService.ValidateLostPassword(nonce) fails and the return Redirect("~/"); is called.
Seeing as direct debugging is a little complex, we acquired a copy of the Controller from source and moved the action code and all related service call logic into an Orchard command for testing. This has succeeded in changing a user's password. and returning without error, using the NOnce captured from the reset email.
So we suspect this may be a bug with Orchard itself though more likely to be with our instance and it's configuration seeing as "Cannot change password" is a pretty expansive issue.
Anyone have any advice to offer? Known bugs that may apply?
Update 1:
Thank you Bertrand. We have not tried it with Orchard 1.9 yet but did manage to get a completely clean 1.8 (as this is the version we are currently running out in the wild from with one of our repos. P.S. Are you aware that your GitHub repo braches go 1.4.x, 1.5.x, 1.9.x? No 1.8.x available. Anyway.) and this worked. The short version: we played around with what could be different and we got it down to it works when our theme is off and doesn't when it on.
A little digging showed that our FE guys has overwritten the Lost Password view to match our business look. Here is what I found:
In the default Orchard view the form is started using:
#using (Html.BeginFormAntiForgeryPost()) {
and ends up looking like
<form action="/OrchardLocal/Users/Account/LostPassword?nonce=Vc7ABvKcwfMO0jrRkJFxiBWoJzbdGAqQ7bbEgGySqlyAAKnHPTIkyhzG8nn%2FXJsqKkh6e9sreTnHx223BKFOs17gY%2FDWMggtCZw%2BSfz194Mviua5smhl5d%2FnACXCI%2BrdQaGcJj%2BjvoFE7m2OIiaX8w%3D%3D" method="post">
all fine and dandy. I presume that because the nonce came in as a query param on the get, it is persisted to the post through inference in calling the default Begin Form without any additional settings.
However, our override currently uses:
#using (Html.BeginFormAntiForgeryPost(Url.Action("LostPassword"), FormMethod.Post, new{ #class="form-lost-password"} ) ) {
Here we specify some additional class for the needs of our theme and on the page we get:
<form action="/Users/Account/LostPassword" class="form-lost-password" method="post">
The nonce has disappered (or rather has not been added at all since we are specifying an particular route). So the ready solution is the add the nonce on using the
Action(String, String, Object)
form of Url.Action() to specify it as a route value.
However, the nonce is not passed through as either a member on the Model nor through the ViewBag (like the minimum password length is).
I found this this previous question from the time of Orchard 1.6/1.7 which suggests updating the controller to add the nonce to the Viewbag but we are using a pre-compiled re-dist of Orchard so this is less than ideal for our needs.
I will be other ways of writing that form using what we have available to us without updating the Controller but is there any plan to make the nonce available to this view for use?
I have the snipped in the index.html but do I need to include it in all other pages? I've tried to work around it but nothing seems to work other than including it in the header of each html file.
In order to use this, the Segment analytics.js snippet must be included on every page (not necessarily the header, though that would be the easiest). The js snippet uses cookies to manage the session and state of the user, so if you want a unified picture of the user's actions on your page, it must be loaded on every page.
More details here:
https://segment.com/docs/libraries/analytics.js/quickstart/
I am having trouble with script link custom actions. I am building a SharePoint app, and I successfully added a site-scope custom action pointing to a script file in the Style Library, as I want this particular script to be injected to all the pages of my SharePoint site.
While it works in certain situations, the script link injection breaks without apparent reason under certain conditions. For example, when I arrive on my root web, the script will be injected. But, if I go to a certain link within this web (for example Home or Site Contents), the file that is supposed to be injected will simply not be fetched from the Style Library and therefore never be injected, resulting in an uncaught ReferenceError when I try to call one of the script's function. The weirdest part is that a page refresh through Ctrl+F5 will fetch the script file without any problem, regardless of the page's ability to originally fetch the script file when first accessed. It will keep the script until it is accessed through a link again.
I've read up on Sharepoint caching, thinking it may be the cause of my problem, but the trouble is that these articles mostly talk about cache-induced errors when updating a file, while I am only trying to access it.
One thing to note is that, due to limitations, I am adding the script link custom action through code. Here's an example of what this kind of call currently looks like in my app:
context.Load(context.Site.UserCustomActions);
context.ExecuteQuery();
customAction.Name = "MyScriptLink";
customAction.Location = "ScriptLink";
customAction.Sequence = 100;
customAction.ScriptSrc = "~SiteCollection/Style Library/MySite/MyScript.js";
customAction.Update();
context.ExecuteQuery();
So, what's going on here ? Why is my script no injected on certain pages ? Why does a refresh on these exact same pages manage to fetch the file without any problem ?
Found it ! Three words: Minimum Download Strategy. Disable it, it messes with you page redirect behavior within a SharePoint site (either through code or through site settings)
Edit: If you still want MDS enabled on your site, there is a solution
I'm working on a JSF page that needs to have the corporate privacy policy updated. Rather than copy-and-paste the new text, I'd prefer to have the PrimeFaces dialog that displays it link to the privacy policy elsewhere. So, I'm doing this:
<p:dialog id="dlgPrivacyPolicy">
<ui:include src="https://cdn.mycompany.com/privacy/en-us/privacy.htm"/>
</p:dialog>
The problem is, the HTML on that page is slightly malformed; there's a <meta> tag that isn't closed. This causes my JSF page to fail to compile.
I could track down whoever maintains that page and ask them to correct it, but that's a band-aid. If any more malformed HTML shows up on that page, it will crash mine. And having my page fail to load because the privacy policy didn't close a tag just isn't acceptable.
Is there a safe way for me to insert potentially malformed HTML into my page? Or am I stick with copying and pasting if I really want to avoid that issue?
If you don't want xhtml compilation problem, you should not include the malformed page in server side but in client side, for example by running ajax request on it and include it by using innerHtml attribute of the dlgPrivacyPolicy div.
Using JQuery :
$.ajax({
url: "https://cdn.mycompany.com/privacy/en-us/privacy.htm"
})
.done(function( html ) {
$( "#dlgPrivacyPolicy " ).html( html );
});
Considering your requirements (mentioned in your question and comments) I'd suggest to use jsoup: You can fetch the html content server-side, sanitize it and then use the sanitized content on your page. The sanitizing step is completely up to you (and jsoup's great capabilities) which can include removing unused/unsafe parts of the page (i.e. headers, css etc) as required.
I'm afraid that including a complete HTML page verbatim is always going to be painful. There's the risk of malformed HTML, or the page might do funny things like overwrite CSS styles, pollute global Javscript scope or whatever.
I think the only clean, maintainable solution will be to agree on some kind of (web) service that provides the privacy policy in a well-defined format (HTML, XHTML, whatever) suitable for inclusion elsewhere. This also makes sure the provider of the privacy policy does not suddenly decide to change the URL, or include a popup or similar. The important point is that the service is an official service with agreed-upon rules.
If you cannot get that service, you'll have to find workarounds. The best I can think of would be to filter the policy through some tolerant HTML parser on your side to fix it (at runtime, or as part of the build). Then you can also fix things like over-eager CSS rules or bad Javascript, as applicable.
All,
I am trying to add Spring Security(3.0.7) to my web application(Spring 3.0.6, Tiles 2.2). The default <form-login/> works as expected, but I can't create a custom one that does. Some issues encountered:
Every time a user clicks on the login link, the login page gets called twice
The UserDetailsService throws an Exception if the user doesn't exist, but the exception never gets picked up anywhere and used. This causes the <form-login/> to reroute to the login-page instead of the authentication-failure-url
I never see error messages when logging in with a bad username (This may be due to the previous issue mentioned above)
After a successful login, sometimes it will open to the correct page, other times it will randomly open up a javascript file that was being referenced inside the page.
I've followed all the tutorials out there and cannot come up with anything working. Does anyone happen to know the class responsible for creating the default login? Perhaps I can look at the source code and mimic what they have.
Has anyone experienced weird behavior like this?
I figured out 2 of my issues. I'm posting them in case anyone else has the same thing happen.
For #1/#4: The site was using tiles, and a default html header block was used throughout the site.
<html>
<head>
<script src="foo.js" type="text/javascript">
</head>
The configuration explicilty blocked this javascript file for users who were not logged in.
<intercept-url pattern="foo.js" access="isAuthenticated()"/>
So when a user came to the home page, the site would load except for foo.js. Since the methods in foo.js never get called before logging in, everything seemed to work fine.
However when someone tried to log in, Spring Security saw foo.js as the first protected page to show, and automatically opened it up.
This also caused the login page to be called twice. Once for the actual login link, and once for the foo.js file.