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.
Related
In my application code, there are a lot of calls (like 100+) to the "top object" referring to window.top such as top.$("title") and so forth. Now, I've run into the problem using Cypress to perform end-to-end testing. When trying to log into the application, there are some calls to top.$(...) but the DevTools shows a Uncaught TypeError: top.$ is not a function. This resulted in my team and I discovering that the "top" our application is trying to reach is the Cypress environment itself.
The things I've tried before coming here are:
1) Trying to stub the window.top with the window object referencing our app. This resulted in us being told window.top is a read-only object.
2) Researching if Cypress has some kind of configuration that would smartly redirect calls to top in our code to be the top-most environment within our app. We figured we probably weren't the only ones coming across this issue.
If there were articles, I couldn't find any, so I came to ask if there was a way to do that, or if anyone would know of an alternate solution?
Another solution we considered: Looking into naming window objects so we can reference them by name instead of "window" or "top". If there isn't a way to do what I'm trying to do through Cypress, I think we're willing to do this as a last resort, but hopefully, we don't have to change that, since we're not sure how much of the app it will break upfront.
#Mikkel Not really sure what code I can provide to be useful, but here's the code that causes Cypress to throw the uncaught exception
if (sample_condition) {
top.$('title').text(...).find('content') // Our iframe
} else {
top.$('title').text(page_title)
}
And there are more instances in our code where we access the top object, but they are generally similar. We found out the root cause of the issue is that within Cypress calls to "top" actually interface with Cypress instead of their intended environment which is our app.
This may not be a direct answer to your question, it's just expanding on your request for more information about the technique that I used to pass info from one script to another. I tried to do it within the same script without success - basically because the async nature of .then() stopped it from working.
This snippet is where I read a couple of id's from sessionStorage, and save them to a json file.
//
// At this point the cart is set up, and in sessionStorage
// So we save the details to a fixtures file, which is read
// by another test script (e2e-purchase.js)
//
cy.window().then(window => {
const contents = {
memberId: window.sessionStorage.getItem('memberId'),
cartId: window.sessionStorage.getItem('mycart')
}
cy.writeFile(`tests/cypress/fixtures/cart.json`, contents)
})
In another script, it loads the file as a fixture (fixtures/cart.json) to pull in a couple of id's
cy.fixture(`cart`).then(cart => {
cy.visit(`/${cart.memberId}/${cart.cartId}`)
})
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 get the following error within Magento CE 1.6.1.0
Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: Cannot send session cookie - headers already sent by (output started at /home/dev/env/var/www/user/dev/wdcastaging/lib/Zend/Controller/Response/Abstract.php:586) in /home/dev/env/var/www/user/dev/wdcastaging/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php on line 119
when accessing /api/soap/?wsdl
Apparently, a session_start() is being attempted after the entire contents of the WSDL file have already been output, resulting in the error.
Why is magento attempting to start a session after outputting all the datums? I'm glad you asked. So it looks like controller_front_send_response_after is being hooked by Mage_Persistent in order to call synchronizePersistentInfo(), which in turn ends up getting that session_start() to fire.
The interesting thing is that this wasn't always happening, initially the WSDL loaded just fine for me, initially I racked my brains to try and see what customization may have been made to our install to cause this, but the tracing I've done seems to indicate that this is all happening entirely inside of core.
We have also experienced a tiny bit of (completely unrelated) strangeness with Mage_Persistent which makes me a little more willing to throw my hands up at this point and SO it.
I've done a bit of searching on SO and have found some questions related to the whole "headers already sent" thing in general, but not this specific case.
Any thoughts?
Oh, and the temporary workaround I have in place is simply disabling Mage_Persistent via the persistent/options/enable config data. I also did a little bit of digging as to whether it might be possible to observe an event in order to disable this module only for the WSDL controller (since that seems to be the only one having problems), but it looks like that module relies exclusively on this config flag to determine it's enabled status.
UPDATE: Bug has been reported: http://www.magentocommerce.com/bug-tracking/issue?issue=13370
I'd report this is a bug to the Magento team. The Magento API controllers all route through standard Magento action controller objects, and all these objects inherit from the Mage_Api_Controller_Action class. This class has a preDispatch method
class Mage_Api_Controller_Action extends Mage_Core_Controller_Front_Action
{
public function preDispatch()
{
$this->getLayout()->setArea('adminhtml');
Mage::app()->setCurrentStore('admin');
$this->setFlag('', self::FLAG_NO_START_SESSION, 1); // Do not start standart session
parent::preDispatch();
return $this;
}
//...
}
which includes setting a flag to ensure normal session handling doesn't start for API methods.
$this->setFlag('', self::FLAG_NO_START_SESSION, 1);
So, it sounds like there's code in synchronizePersistentInf that assumes the existence of a session object, and when it uses it the session is initialized, resulting in the error you've seen. Normally, this isn't a problem as every other controller has initialized a session at this point, but the API controllers explicitly turns it off.
As far as fixes go, your best bet (and probably the quick answer you'll get from Magento support) will be to disable the persistant cart feature for the default configuration setting, but then enable it for specific stores that need it. This will let carts
Coming up with a fix on your own is going to be uncharted territory, and I can't think of a way to do it that isn't terribly hacky/unstable. The most straight forward way would be a class rewrite on the synchronizePersistentInf that calls it's parent method unless you've detected this is an API request.
This answer is not meant to replace the existing answer. But I wanted to drop some code in here in case someone runs into this issue, and comments don't really allow for code formatting.
I went with a simple local code pool override of Mage_Persistent_Model_Observer_Session to exit out of the function for any URL routes that are within /api/*
Not expecting this fix to need to be very long-lived or upgrade-friendly, b/c I'm expecting them to fix this in the next release or so.
public function synchronizePersistentInfo(Varien_Event_Observer $observer)
{
...
if ($request->getRouteName() == 'api') {
return;
}
...
}
I need to display, for example, the "Bad credentials" message in another language.
So far I found that it is thrown as an exception in
\vendor\symfony\src\Symfony\Component\Security\Core\Authentication\Provider\UserAuthenticationProvider.php
authenticate function as
throw new BadCredentialsException('Bad credentials', 0, $notFound);
I am wondering what would be the recommended way for showing this message in another language. Just changing the string in this place seems non-optimal...
Also there are other messages that might probably be shown during authentication.
I am using the JMSSecurityExtraBundle and FOSUserBundle and I guess there could be some built in functionality to handle this...?
Override login template: copy FOSUserBundle/Resources/views/Security/login.html.twig to app/Resources/views/Security/login.html.twig (see doc, video)
Add trans filter to error variable in login.html.twig (see doc):
{{ error|trans }}
In your translate file src/YourBundlePath/Resources/translations/messages.{locale}.yml add:
Bad credentials: Your error text
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.