hi i'm new to ava testing. I am able to test for pages that are shown to non logged in users. Now i would like to test for logged in users which means the pages will change accordingly. How do i test for such a scenario? My best guess is to use Phantomjs or nightmarejs with ava.
Related
I am writing ember acceptance tests, and when redirecting as in
visit('/get-started');
it actually visits the page in the browser, redirecting away from /tests.
Any thoughts on what could be causing this?
I am on Ember 2.11.0
I think this behaviour is by design. When you visit('/get-started'); in your acceptance test, it should navigate to the given path in the browser, and perform whatever acceptance criteria you are trying to test.
I'm not sure what your acceptance criteria is for the /get-started page, but if you wanted to simply test that the navigation was successful, your test might look like:
test('navigate to /get-started', function(assert) {
visit('/get-started');
andThen(function() {
assert.equal(currentPath(), 'get-started');
});
});
I'm not sure how acceptance tests worked in older versions, but for the current version(2.11.0), I think it is working as intended.
I have read something about TDD. My field is web development.
Namely server side (Python + Django).
In a book I read: let's check whether our local web page has a 'html' tag.
I would say that for learning purposes it is ok. But a real web page should be validated by https://validator.w3.org/
They say that even for famous web sites not every page passes the validation. Well, let us assume that we decided to develop a nice web site and our policy is 100 % passing of the validation.
Well, the plan seems to look like we should automatically submit our web page to the validator and check for errors. How can it be done?
By the way, I don't have a public IP.
Is it a good plan to:
1) Pay more to ones Internet provider and get a public IP.
2) Run a webserver in debug mode. In this case at the development stage the web site will be visible from a real world.
3) Pass the address of the web page being developed to the validator via Selenium?
4) Check for errors via Selenium again.
Is it a good idea or is there a better plan? Can I get by without a public IP?
You can download a copy of the W3C validation program and run it locally.
There are also a number of other offline HTML validators such as HTML Tidy and Total Validator.
You might also consider running the validation as a part of continuous integration. There are plugins for Jenkins and other CI servers such as the Unicorn Validation plugin.
I don't see any error messages in the log file, and there is no message on the screen. Logging in to my Rails 3 app as it is served up in an iframe from another site results in being returned to the main site without the user being logged in.
It sounds like the Rails app is not recognizing the cookie through the iframe. Has anyone else run into this problem? Where could I go to see what the error is?
Please note this ONLY occurs in IE, version 8 (maybe it occurs in 7 and 6, haven't tested yet).
James is correct, IE has some security in place to prevent iFrames from generating cookies. There's an easy fix for this, simply include the following response header into your controller:
response.headers['P3P'] = 'CP="NON DSP COR CURa IVAa IVDa CONa OUR NOR STA"'
Source: http://adamyoung.net/IE-Blocking-iFrame-Cookies
I had similar problems with IE 6 and 7 and Devise with iframes. From my understanding it has something to do with sessions not being passed through iframes in IE. According to what I was able fo find, IE prevents this for security.
I'm not sure why this only seems to be a security issue in IE and not other browsers.
I think I'm missing a very obvious solution here, but I'll ask anyway. I've got a grails application that uses the Spring Security Plugin for my AAS. I want to start doing daily build and deploys of the application using Hudson onto a test server (running Apache2/Tomcat6) as the ROOT application. When the application goes live, anonymous users will be able to access the site, along with registered users. However, during the testing/development phase I want to restrict users to those who have been invited.
I've created logic to generate an invitation code, and a temporary "login / registration on invite" view to be used during this dev/test phase. Currently I'm using a filter to redirect any non-logged in users to that view. The problem is the filter is catching any request, so any additional applications (IE Bugzilla), URL's that would normally invoke a 404, etc are also being filtered, and the user is redirected to that same login page, even if they are already authenticated.
I had opted to go the filter route, instead of modifications to Spring Security settings, since this process is only a temporary solution, and I feel it will be much easier to remove at a later date. Is this a good Idea or is really not worth the hassle? What is the proper way to force only users of the application to log-in, but ignore requests to other URLs?
The problem doesn't seem to be in your web-app, hence not in Spring Security. It is probably in the Tomcat or Apache settings. If set up correctly, the request to other context path should never have hit your ROOT web-app in the first place.
Fogbugz-on-demand, 37 signals, and PB-Wiki all use sub-domains with custom url's for each group of users to access their login page. So it doesn't even seem possible for a user using those services to login to a generc login (that any user of the service could log into.)
At first I thought this was a terrible design flaw, but now I think this is a really good idea because of:
1) Additional security, it may not be much, but you now need 3 pieces of info: 1 sub-domain url, 2 login, 3 password
2) You can let the same login log into different accounts by the subdomain url.
3) This lends itself to more isolation, load balancing, and easy deployment since you can have the subdomains running under different servers in more isolation from each other.
4) You can gradually roll out changes to a certain set of sub-domains that are marked as BETA users before deploying them to all users.
Are sub-domain based logins for web applications the future? Are there pitfalls with this design approach I'm not seeing? Is it too confusing for non-programmer users to understand the sub-domain concept?
We went with a triple-element login instead. We ask for the username, password, and client-id. Same concept as the sub domains but there's a common login URL. That works fine too. However, I do see an advantage in the sub-domain process, you can brand the login page because you know the requested client. In our approach we can't brand the login page since we don't know the client until you submit the login page.