I'm looking for a good way to handle errors in Zope's page templates. What I already know is:
<div ... tal:define=...
tal:on-error="string:Oops!">
This text will be replaced in case of errors
</div>
or
<div ... tal:define=...
tal:on-error="error/value">
This text will be replaced in case of errors
</div>
or
<div ... tal:define=...
tal:on-error="string:${error/type}: ${error/value}">
This text will be replaced in case of errors
</div>
However, it might be desirable to use a more elaborated error handling method, e.g.
to display details depending on certain permissions
to log and/or report the error to the maintainers
to have an easy way to create some pretty HTML without the need of a lot of code in the template
I had a look at the old Zope documentation page and created a script object like described there (amending the missing colon, of course); however, it won't work (I tried both on-error="here/errHandler" and on-error="here/scripts/errHandler", and I added *args and **kwargs, without success).
I tried to build a browser (on-error="here/##talerror") for such purposes, and it was used alright, but it didn't seem to get the error object.
I'm using Zope 2.10.7-final and Plone 3.3 (old, I know).
Is there a way to hand over the error object to the browser, or to make the script object work?
P.S., just to get it clear: This is not about sqeezing lots of logic in a template - no sermons about templates and logic, please! My goal is to find the error in existing templates, i.e. which part of the logic (which is implemented somewhere behind the scenes, in browsers etc.) fails in which way. The documented way of using an error script doesn't work for me (maybe I'm missing an important part?), and an error handling browser apparently doesn't have access to the error object.
Related
I have recently become aware of Confluence's servlet-filter module. However, after trying to get it to work, I have run into a dead end. I am getting my information here:
https://developer.atlassian.com/confdev/confluence-plugin-guide/confluence-plugin-module-types/servlet-filter-module
Here is what I tried. I annotated my atlassian-plugin.xml file like so:
<servlet-filter name="My Test Filter" key="OURAPP" class="com.test.filters.HelloWorldFilter" location="after-encoding" weight="100">
<description>Forwards you to a test "Hello, world!" page.</description>
<url-pattern>/helloworld</url-pattern>
<dispatcher>REQUEST</dispatcher>
</servlet-filter>
Then, I created a standard Java servlet (extends HttpServlet, etc.) at com/test/filters called HelloWorldFilter.java. In the "doGet()" method, I simply have a System.out.println() line that reads "IN THE FILTER". However, when I go to the following URLs, I always get the "Page Not Found" error page:
http://127.0.0.1:8090/helloworld
http://127.0.0.1:8090/OURAPP/helloworld
http://127.0.0.1:8090/plugins/OURAPP/helloworld
http://127.0.0.1:8090/rest/helloworld
http://127.0.0.1:8090/rest/OURAPP/helloworld
http://127.0.0.1:8090/OURAPP/rest/helloworld
We have a custom Confluence plugin, lets call it OURAPP, that is serving up data not only through the browser GUI, but also through Confluence's REST capabilities. I am trying to create a filter that manages valid and invalid requests alike. We can access the REST at:
http://127.0.0.1:8090/rest/reststuff/v1/some_function_here
Like I said in the beginning, I have run into a dead end here, and cannot figure out how to get this to work. Can anybody offer up any suggestions or example code of how to get this working?
After a couple of days messing around with this, I FINALLY figured out what was wrong. I was extending javax.servlet.http.HttpServlet instead of implementing javax.servlet.Filter. After I changed to implementing Filter, and implemented all the proper methods, my servlet filter started to work at 127.0.0.1:8090/helloworld. There are a number of examples out there that use a standard Java Servlet (i.e., extending HttpServlet) but that [apparently] does not work with Confluence. I hope this helps somebody else out there struggling with Confluence's confusion. Thanks to all who took the time to read.
Your dispatcher tag is missing the closing ">":
<dispatcher>REQUEST</dispatcher
Regards,
Gorka
I am trying to load a template with xhr and then append it to the page in some div.
the problem is that the page loads the script but doesn't execute it.
the only solution I got is to add some flags in the page (say: "Splitter"), before the splitter, I put the js code, and after the splitter I add the html code, and when getting the template by ajax, I split it. here is an example:
the data I request by ajax is:
//js code:
work_types = <?php echo $work_types; ?>; //json data
<!-- Splitter -->
html code:
<div id="work_types_container"></div>
so the callback returns 'data' which I simply split and exeute like this:
data = data.split("<!-- Splitter -->");
dojo.query("#some_div").append(data[1]); //html part
eval(data[0]); //js part
Although this works for me, but it doesn't seem so professional!
is there another way in dojo to make it work?
If you're using Dojo, it might be worth to look at the dojox/layout/ContentPane module (reference guide). It's quite similar to the dijit/layout/ContentPane variant but with one special extension, that it allows executing the JavaScript on that page (using eval()).
So if you don't want to do all that work by yourself, you could do something like:
<div data-dojo-type="dojox/layout/ContentPane" data-dojo-props="href: myXhrUrl, executeScripts: true"></div>
If you're concerned about it being a DojoX module (DojoX will disappear in Dojo 2.0), the module is labeled as maintained, so it has a higher chance of being integrated in dijit in later versions.
As an anwer to your eval() safety question (in comments). Well, it's allowed of course, else they wouldn't have such a function called eval(). But indeed, it's less secure, the reason for this is that the client in fact trusts the server and executes everything the server sends to the client.
Normally, there are no problems unless the server sends malicious content (this could be due to an issue on your server or man in the middle attacks) which will be executed and thus, causing an XSS vulnerability.
In the ideal world the server only sends data and the client interpretes this data and renders it by himself. In this design, the client only trusts data from the server, so no malicious logic can be executed (so there will be no XSS vulnerability).
It's unlikely that it will happen and the ideal world solution is not even possible in many cases since the initial page request (loading your webpage) is in fact a similar scenario where the client executes whatever the server sends.
Web application security is not about being 100% safe (it's impossible), but it's to try to create as less as possible open doors that can be used by hackers. It's up to you what you consider safe and to verify if the "ideal world" solution is possible in this specific scenario (it might not be, or it might take too much time compared to the other solution).
All of a sudden the errors that Dojo (1.8.3 from Google CDN) is spitting out empty errors, which makes debugging impossibly hard. For example, if I forget to require a dependent before using it, I get the usual
> dojo/parser::parse() error ReferenceError {}
... in the error console, but I remember getting more information in the ReferenceError (spindown arrow was present), giving me the arguments of the error as well as the message making it easy to figure out what I had done wrong.
I have isDebug : true in my dojoConfig, but it just doesn't want to tell me anything anymore.
What gives?
I've been having the same problem using Dojo 1.8.3 as well. When I close my developer tool's console and then re-open it the Error had the spindown and more details as expected. Seems stupid, but give it a try and see if that at "fixes" it for you. I planned on digging a little further into this later, so if I find any additional details I will make sure to update my answer with them.
I'm using webflows in Grails and I'm currently writing tests for it. Now, inside I've got something that throws an error so I set a message to the flash scope before redirecting:
...
if (some_condition) {
flash.message = "my error message"
return error()
}
...
Now, I know that when I'm going to display this in the GSP page, I access the flash message as
<g:if test="${message}">...
instead of the usual
<g:if test="${flash.message}">...
So anyway, I'm writing my test and I'm wondering how to test the content of the message? Usually, in normal actions in the controllers, I follow what's written in here . However, since this is a webflow, I can't seem to find the message even if I check controller.flash.message / controller.params.message / controller.message . I've also tried looking at the flow scope...
Any ideas on how to see the message then? Thanks a bunch!
Based on your example, you can access your flash.message as controller.request.message in your webflow test. I did a lot of googling for this same exact issue and a lot of webflow documentations talk about it merging all scopes into the "view model". But I also read somewhere that it merges the flash scope into the request scope for redirection. That's what prompted me to try looking in the controller.request in my test case.
We're using WatiN to test our web portals. During the course of an E2E test, we'll occasionally see client-side script errors on the IE status bar. I'd like to chain a handler onto the script error event and record the error for later analysis and bug filing.
Problem is, I don't know that there's a global script error event or how to chain into it. And if there's not a browser-agnostic way to accomplish this, I can create MyIE and MyFF subclasses but then this becomes two browser-specific questions.
In essence, I'm thinking of something like this entirely made-up call:
browser.ScriptEngine.SetCustomErrorHandler(LogScriptingError);
... where LogScriptErrors is my code that does the obvious.
Many of our client-side scripting errors don't necessarily prevent the test from continuing (a pretty UI element didn't animate, for example, but the underlying form is still submittable), so I'd like to log the error and forge ahead in most cases.
You probably looking for this:
window.onerror=function(message, url, line){logError();};
You can add this code to your pages to handle errors in logError(). but this may not work in all browser(works in IE), check this for browser compatibility:
http://www.quirksmode.org/dom/events/error.html
Or you may try this commercial product:
exceptionhub.com/
You could maybe co-opt the ability to inject eval code (described under "Added Eval functionality") to add a script that caught all errors, not just errors from the eval'ed script. I'm not sure if this would work, but it's an area to explore. Another resource might be this blog post, which discusses how to evaluate Javascript in WatiN.