Regex in capybara have_xpath - regex

I have a text changing decoration when it is clicked. In my tests before clicking I want to check whether it's already clicked or not. It changes color, text decoration and href which I want to check through.
As href contains session specific information, so I want to use regex.
if page.have_xpath("//a[contains(#href,\"%20Administrators?\")]")
This passes even the page has already been updated and Administrators text has changed to something else.
How should I correct the syntax to accept all href containing "%20Administrators?" text. I want add it to if clause as if the page has the link with text Administrators in it.
Before clicking: href="/sometext/%20Administrators?redirect=sometext"
After clicking : href="/sometext/%20Standard?redirect=sometext"

The primary issue you're having here is using have_xpath rather than has_xpath?. have_xpath returns an RSpec matcher, and as such when used with if will always evaluate as true (since it returns an object and hasn't yet actually evaluated any XPath passed in). has_xpath? returns a boolean result of true or false.
if page.has_xpath?('.//a[contains(#href,"%20Administrators?")]')
The second issue is that your question asks about regex, but XPath 1.0 (which browsers support) doesn't have regex support and your XPath isn't using regex at all (just a contains expression). If you actually want to use regex for testing the href (and have better reading code) you should be using the has_link? boolean method - along the lines of
if page.has_link?(href: /Administrators/)
has_link? can also verify the visible text of the link too if wanted
if page.has_link?('Visible text of the link', href: /Administrators/)
Finally, when using XPath with Capybara, 99% of the time you should start your XPath with .// instead of just // - see https://github.com/teamcapybara/capybara#beware-the-xpath--trap - and is one reason why it's usually cleaner to use CSS and/or the more specific methods provided by Capybara rather than the xxx_xpath methods.
One other thing to note is that all of the methods mentioned have waiting behavior by default, so they will wait up to Capybara.default_max_wait_time seconds for the page to have a matching link. If you know the page is stable and just want to immediately know whether or not a matching link exists you might want to pass wait: false as an option
if page.has_link?(href: /Administrators/, wait: false)

Related

In group settings API, what is "customFooterText" supposed to do?

I'm trying to figure out what the property "customFooterText" in https://www.googleapis.com/groups/v1/groups/groupUniqueId does.
The docs say
Set the content of custom footer text. [..]
so I played around with it (in combination with a true "includeCustomFooter". I also tried different states of directory-wide footer in the admin-panel) because I have a use case for setting different footers for different groups, but it does not seem to do anything.
Any input would be highly appreciated.
Yes. Based from the documentation, customFooterText is used to set the content of custom footer text. The maximum number of characters is 1000. You may check this link on how to use it in your code.
{
...
"includeCustomFooter": string,
"customFooterText": string,
...
}
You may also refer with this related thread:
Title footer for Group in Setting bundle

RenderComponentPresentation before any other markup Tridion Razor Page

I have a page template in Tridion 2011 with Razor code that prints information based on RenderComponentPresentation() as the first thing in the page. No other markup comes before it, because the component, not the page, contains the initial markup. Unless I put at least one character before the first RenderComponentPresentation in the published output, the template refuses to render any presentations.
So, for example, if this is all that is in the layout TBB this works (in my real code the tcms are real of course):
<
#RenderComponentPresentation("tcm:mytcm","tcm:myothertcm")
but this does not
#RenderComponentPresentation("tcm:mytcm","tcm:myothertcm")
The first prints the contents of the component preceded by the "<", whereas the second does nothing at all. I don't want to have ANY markup directly at the start of the page template, I want the first thing to be the component. Is it possible?
I've just done a quick test in Template Builder using the latest version of the Razor Mediator (1.2) and couldn't replicate your issue.
Maybe you could try:
<text></text>
#RenderComponentPresentation("tcm:mytcm","tcm"myothertcm")
It won't render any additional markup but may trick the mediator into doing what you want (though like I said, I can't replicate your problem so can't verify whether it does).
Normally with Razor you iterate over any and all Component Presentations on the page, and right now I'm working with
#foreach(var cp in ComponentPresentations){
#cp.RenderComponentPresentation()
}
This will render every component on the page, regardless of predefined schema's or templates. Your issue however suggest a problem elsewhere. What kind of output does your page template generate (do mind its the page template using a compound template which in turn includes the Razor TBB you describe here). Is it .aspx, HTML or other? And what is the Component templates' output? is it an HTML fragment, or anything else?
As far as you syntax goes, that should be just fine other than the template invocation:
#RenderComponentPresentation("tcm:x-xxx-xx", "tcm:xx-xxx-xx")
I have a feeling this code only works when used within HTML tags, though, but that's just a hunch.
Bit of a hack but have you tried:
<text>#RenderComponentPresentation("tcm:x-xxx-xx", "tcm:xx-xxx-xx")</text>
or
#Html.Raw(RenderComponentPresentation("tcm:x-xxx-xx", "tcm:xx-xxx-xx"))
Disclaimer: not really used Razor mediator. Just Razor.

C++, web browser control: cannot change encoding/charset

There's a document I'm displaying in a web browser ActiveX control hosted in a C++ app. This document has a META tag that specifies incorrect charset, so the output is funny. I know the correct encoding and want to change it programmatically to fix that. But whatever I try, the encoding remains unchanged.
I alredy tried, in various combinations and flavors:
IHTMLDocument2::put_Charset (after the document finished loading);
changing the "charset" property of the "META" tag (using IHTMLMetaElement);
deleting the "META" tag altogether (by setting its "outerHTML" to empty string);
refreshing the control.
The control demonstrates remarkable persistence in preserving the incorrect encoding. What are my other options? I can't manipulate the source of the document being loaded.
try to put the designMode property "On".
According to this, it should work if you call IWebBrowser->Refresh() after calling IHTMLDocument2->put_charset().
Here's what eventually worked:
In the handler of the "NavigateComplete2" browser event,
the charset is modified using the charset property,
then the META tag is thrown away by setting its outerHTML to empty string,
and then the control is refreshed.
Modifying the order of these actions, or omitting a step, will render the entire operation void. MSHTML is picky.

Regex with iframe in Yahoo! Pipes

I'm building a Yahoo! Pipe to pull an RSS feed from Reddit which links to some content in the description. I'm using a regex to match the href attribute of the anchor link in an item.description field. The regex I'm using is:
^.+?href="([^"]+)">\[link\].+?$
As a test, I set the replace to simply:
$1
and I see that the entire description field has been replaced with the URL. So far, so good.
I then put the following in the replace field. The idea being to iframe the content that's linked to:
Content: <iframe src="$1">no iframe support</iframe> End
What I get out however is:
Content: no iframe support End
I've confirmed that this is also coming through in the pipe's output and not just in the Yahoo! Pipes debug console.
I've so far tried replacing my angle brackets with < and > entities. I've tried wrapping the entire thing in a <![CDATA[ ... ]]> block and still, I get nothing. If I break my iframe tag by removing an angle bracket, the broken content comes through fine, but if I have a well-formed iframe element, it vanishes, leaving the "no iframe support" text. Am I doing something wrong here, or is Yahoo! actively preventing me from using iframe tags in my generated pipe? A cursory search on Google isn't turning up anything related to this.
The pipe in question is here:
http://pipes.yahoo.com/pipes/pipe.info?_id=2ba41448cadd2347d86f377efd3d199f
This Pipes FAQ Question "Why does Pipes Strip <object> and <embed> tags... ?" shows that a certain amount of sanitization is performed, by placing content (at least certain content) into an iframe for the safety of RSS consumers - though it does not state it specifically, this probably also removes other iframes in order to avoid nesting and other work-arounds.
Yahoo is big enough I would doubt they have a week sanitizer, but an extremely long shot is that you might be able to fool it by nesting the iframe in a bunch of other tags (again I doubt this will work). Also depending upon which step does the sanitization, perhaps adding part of the tag in one step, then adding another part somewhere else might work (yet again, doubt overwhelms me)
Not sure what else to suggest, other than getting something else to consume and transform your RSS a little bit more (by fixing otherwise broken tags??) - but that's what you're using pipes for to begin with, isn't it? Idunno...
Good luck!
Pipes has an fanatical devotion to the RSS spec and the spec says the description field is plain text only. HTML etc is supposed to go in the content:encoded field, not that I've had much luck getting pipes to do that.

How to not transform special characters to html entities with owasp antisamy

I use Owasp Anti samy with Ebay policy file to prevent XSS attacks on my website.
I also use Hibernate search to index my objects.
When I use this code:
String html = "special word: été";
// use the Ebay configuration file
Policy policy = Policy.getInstance(xssPolicyFile.getInputStream());
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(html, policy);
// result is now : "special word: été"
result = cr.getCleanHTML();
As you can see all chars "é" has been transformed to their html entity equivalent "é"
My page is on UTF-8, so I don't need this transformation. Moreover, when I index this text with Hibernate Search, it indexes the word with html entities, so I can't find word "été" on my index.
How can I force antisamy to not transform special chars to their html entity equivalent ?
thanks
PS: an issue has been opened : http://code.google.com/p/owaspantisamy/issues/detail?id=99
I ran into the same problem this morning.
I have encapsulated antisamy in a class and I use apache StringEscapeUtil from apache common-lang to restore special characters.
CleanResults cleanResults = antiSamy.scan(taintedHtml);
cleanedHtml = cleanResults.getCleanHTML();
return StringEscapeUtils.unescapeHtml(cleanedHtml)
The result is a cleaned up HTML without the HTML escaping of special characters.
Hope this helps.
Like Mohamad said it in a comment, Antisamy has just released a new directive named : entityEncodeIntlChars
here is the detail : http://code.google.com/p/owaspantisamy/source/detail?r=240
It seems that this directive solves the problem.
After scouring the AntiSamy source code, I found no way of changing this behavior apart from modifying AntiSamy.
Check out this one: http://code.google.com/p/owaspantisamy/source/browse/#svn/trunk/dotNet/current/source/owaspantisamy/html/scan
Grab the source and notice that key classes (AntiSamyDOMScanner, CleanResults) use standard framework objects (like XmlDocument). Compile and run with the binary you compiled - so that you can see everything in a debugger - as in which of the major classes actually corrupts your data. With that in hand you'll be able to either change a few properties on major objects to make it stop or inject your own post-processing to revert the wrongdoing (say with a regexp). Latter you can expose that as additional top-level property, say one named NoMess :-)
Chances are that behavior in that respect is different between languages (there's 3 in that trunk) but the same tactics will work no matter which one you have to deal with.