Cypress/Rails cookie issue preventing user staying signed in - ruby-on-rails

I'm running into an issue which I can't determine the cause off. I have defined the following commands within Cypress:
Cypress.Commands.add('createUser', (opts, permissions = []) => {
railsRequest('create_user', { user: opts, permissions })
.its('body')
.its('response');
});
Cypress.Commands.add('create', (type, opts) => {
railsRequest('create', { type, opts })
.its('body')
.its('response');
});
Cypress.Commands.add('login', { prevSubject: true }, (subject) => {
railsRequest('login', { id: subject.id })
.its('body')
.its('response')
.as('currentUser');
});
The createUser command is fairly self explanatory, the create command allows me to create dummy data on the server and the login command logs the previously created user in to the server setting the session cookie.
I've got the following spec (which currently has no assertions as I'm playing around) which I'm having issues with:
describe('My Spec', () => {
beforeEach(() => {
cy.createUser({}, ['permission_name'])
.login();
});
it('testing', function() {
cy.visit('/');
cy.create('other_resource', { name: 'resource name' }, company_id: this.currentUser.company_id)
.as('resource')
.then(resource => {
cy.visit('/resource');
});
});
});
Nothing particularly complicated, but here is what's going on:
User is created
Login takes place
visits '/' which works properly. Chrome shows the page loading as expected
New 'resource' is created
When ready, visits '/resources' - here however the app redirects to the login page. Seemingly the user has been logged out.
What I don't get is why the user is being logged out. I added in the cookie debugging and see the session cookie being changed on each request so it seems like the session cookie is OK, but something clearly isn't working correctly.
We have no issues with the app itself when running so I don't THINK it's the back end but if someone has any idea of what's going on I'd love some insight

Ok so it was me being an idiot in the cypress controller in rails. I've got a controller responsible for the calls to create data and handle any ruby code, but on the create call it was setting up the test suite for the helpers that it uses, but the method that was responsible for that was also clearing the database. So essentially, the user was being logged in, then when it asked the server to create the dummy data it wiped the database (including the new user) and then tried to continued.
Needless to say any future request resulted in being redirected to the login page because the user didn't exist

Related

Page Object Model Instance in Playwright (TS) Doesn't Use the Global Config Session Storage

I am developing tests for a website that requires login for the whole page. This website uses Google Sign-In for authentication. All of the Google accounts used for authentication require two-factor authentication.
This means to test one part of the website, the test suite needs to sign in for each test three times - which eventually leads to problems with authentication requiring human interaction, or even requiring extra steps to authenticate.
To resolve this problem, I followed the Reuse Signed-In State part of the Playwright documentation so that sign in would happen once and then saved and shared among the tests.
This works fine for just normal tests. However, I also started using Page Object Models to describe my pages and allow for easier maintenance of the test suite. For some reason, in tests that create new instances of Page Object Model classes, the tests do not make use of the saved state and thus are not logged in.
How can this saved state be passed onto a POM instance in Playwright so that signed-in state can be reused? Perhaps I've missed something simple?
Used a global-setup.ts file to declare login:
async function globalSetup(config: FullConfig) {
const browser = await chromium.launch({ headless: false });
const page = await browser.newPage();
await page.goto("http://localhost:8000/login");
await page.getByRole("button", { name: "Connexion" }).click();
await page.getByRole("button", { name: "Continue with Google" }).click();
await page.getByRole("textbox", { name: "Adresse e-mail ou numéro de téléphone" }).fill(process.env.USERNAME);
await page.getByRole("textbox", { name: "Adresse e-mail ou numéro de téléphone" }).press("Enter");
await page.getByRole("textbox", { name: "Saisissez votre mot de passe" }).fill(process.env.PASSWORD);
await page.locator("#passwordNext").click();
await page.goto("http://localhost:8000");
// Save signed-in state to 'storageState.json'.
await page.context().storageState({ path: "storageState.json" });
await browser.close();
}
I also added this to the playwright.config.ts file:
const config: PlaywrightTestConfig = {
globalSetup: require.resolve('./global-setup'),
use: {
storageState: 'storageState.json'
}
};
Here is an example of a test making use of the POM, which then doesn't use the state created in global setup. The login still happens, but then the new browser opened doesn't have the state and thus gets stuck on the login page:
test("apply a filter", async ({ page }) => {
const dashboardHome = new DashboardHome(page);
await new LoginPage(page).login();
await dashboardHome.bookingLink.waitFor();
await dashboardHome.bookingLink.click();
const reservationsPage = new ReservationsPage(page);
await reservationsPage.orderNumberFilter.waitFor();
reservationsPage.filter({ orderID: "22222" });
await expect(page).toHaveURL("http://localhost:8000/booking/22222");
});
I had similar issues with global setup and re-write my global setup in fixture (kinda global) where I used it everywhere. I amn't very experienced in test automation and can't explain why globalsetup didn't work. I also believe it's something simple, that i can't catch. Hope it help you.
That definitely seems confusing, especially since switching to a POM shouldn’t affect it (I have successfully used the POM and this one-time saved and reused auth).
I can’t think how switching to use page objects would affect it, and would be curious to see your setup. But one potential reason for your problem is that I’ve seen and worked with sites where if you go to the login page, you’re automatically “logged out” in some way, thus negating your login during setup. If you already logged in during setup and saved that auth state, you should be able to bypass/skip the login page altogether in the test and go directly to the page you need to work with. I would actually expect/be curious if you run into the same problem when not using the POM.
Let me know if that solution works for you, or if you even still have the issue at this point, but if that’s not the issue I may need more clarification or info to help further.

CasperJS + Authlogic (Rails) - maintain login session between tests

I have a single-page app that has a Ruby on Rails backend and uses Authlogic to facilitate user authentication.
I am implementing functional testing using CasperJS and am having a hard time getting login sessions to persist between sessions but also between thenOpen commands.
I am running the following command:
casperjs --cookies-file=cookies.txt test ../../../foobar/test/casper/login/test.js
Here's an example of my current code:
phantom.cookiesEnabled = true;
var x = require('casper').selectXPath
casper.test.begin('Logging in', 2, function suite(test) {
casper.start('http://localhost:3000/login', function() {
console.log("Page loaded");
test.assertExists('form', 'login form is found');
this.fillSelectors('form', {
'#email': "foo#bar.com",
'#password': "foo_bar"
}, false)
this.click('#submit')
casper.thenOpen('http://localhost:3000/my', function() {
test.assertUrlMatch(this.getCurrentUrl(), 'http://localhost:3000/my', "Logged in and maintained login cookie")
})
})
casper.run(function() {
test.done();
});
})
While watching my dev log, I can see that the first test (casper.start) logs in successfully but after the thenOpen, the Authlogic UserSession is no longer maintained so PhantomJS gets redirected to localhost:3000/login, which is what should happen if there is no logged-in user.
How can I maintain a logged-in session using CasperJS between thenOpen but also between multiple test runs? Can I maintain cookies so that the user remains logged-in between tests?
Seems like this comment saved the day
Looking at the code you have this.click and then doing a
casper.thenOpen I would add another step after the form submission and
use a casper.waitForXXXX.
It does look like a timing issue

Connecting to github with Ember.js and Torii (oauth2)

I'm trying to use the github-oauth2 provider in Torii, but I'm stumped on how I'm supposed to se tup some of the callbacks. I'll trace the code I'm using, as well as my understanding of it, and hopefully that can help pinpoint where I'm going wrong.
First, in my action, I'm calling torii's open method as it says to do in the docs:
this.get('torii').open('github-oauth2').then((data) => {
this.transitionTo('dashboard')
})
And, of course, I have the following setup in my config/environment.js:
var ENV = {
torii: {
// a 'session' property will be injected on routes and controllers
sessionServiceName: 'session',
providers: {
'github-oauth2': {
apiKey: 'my key',
redirectUri: 'http://127.0.0.1:3000/github_auth'
}
}
},
}
The redirectUri is for my Rails server. I have the same redirectUri setup on my github app, so they match.
Here's what I have on my server. It's likely this is where the problem is. I'll get to the symptoms at the end.
def github
client_id = 'my id'
client_secret = 'my secret'
code = params[:code]
#result = HTTParty.post("https://github.com/login/oauth/access_token?client_id=#{client_id}&client_secret=#{client_secret}&code=#{code}")
#access_token = #result.parsed_response.split('&')[0].split('=')[1]
render json: {access_token: #access_token}
end
So I post to github's access_token endpoint, as I'm supposed to, and I get back a result with an access token. Then I package up that access token as json.
The result of this is that the torii popup goes to the rails page:
Unfortunately, what I was hoping for was for the torii popup to disappear, give my app the access_token, and for the code to move on and execute the code in my then block.
Where am I going wrong?
Many thanks to Kevin Pfefferle, who helped me solve this and shared the code to his app (gitzoom) where he had implemented a solution.
So the first fix is to clear my redirectUri, and to set it on github to localhost:4200. This made the app redirect so that it's an Ember app that it's redirected to.
The second fix was to create a custom torii provider
//app/torii-providers/github.js
import Ember from 'ember';
import GitHubOauth2Provider from 'torii/providers/github-oauth2';
export default GitHubOauth2Provider.extend({
ajax: Ember.inject.service(),
fetch(data) {
return data;
},
open() {
return this._super().then((toriiData) => {
const authCode = toriiData.authorizationCode;
const serverUrl = `/github_auth?code=${authCode}`;
return this.get('ajax').request(serverUrl)
.then((data) => {
toriiData.accessToken = data.token;
return toriiData;
});
});
}
});
Not sure why this then triggers but the then I was using before didn't. Anyways, it grabs the data and returns it, and then the promise I was using before gets the data correctly.
this.get('torii').open('github-oauth2').then((data) => {
//do signon stuff with the data here
this.transitionTo('dashboard')
})
So there we go! Hopefully this helps other folks who are stuck in the future.

How can I store and set the user on this angularjs devise library auth service? Or is it being done already?

I am using the cloudspace angularjs-devise library on the client. When I try to login/register I get a 200 ok response with the plain user object visible in the chrome js console. Refreshing the page seems to lose this information even though I assumed that the service would store this at some point since it also has logout and currentUser methods.
https://github.com/cloudspace/angular_devise
My questions are:
1) Is this service actually storing the user and if so how (i.e. with cookies or localstorage or in memory)?
2) If the service does not store the user how can I store this information in a custom cookie/localstorage and more importantly set the user into the service so that the services "isauthenticated" and "currentuser" methods can be used?
Partial Library Readme Instructions
Just register Devise as a dependency for your module. Then, the Auth service will be available for use.
angular.module('myModule', ['Devise']).
config(function(AuthProvider) {
// Configure Auth service with AuthProvider
}).
controller('myCtrl', function(Auth) {
// Use your configured Auth service.
});
Auth.login(creds): Use Auth.login() to authenticate with the server. Keep in mind, credentials are sent in plaintext; use a SSL connection to secure them. creds is an object which should contain any credentials needed to authenticate with the server. Auth.login() will return a promise that will resolve to the logged-in user. See AuthProvider.parse() for parsing the user into a usable object.
angular.module('myModule', ['Devise']).
controller('myCtrl', function(Auth) {
var credentials = {
email: 'user#domain.com',
password: 'password1'
};
Auth.login(credentials).then(function(user) {
console.log(user); // => {id: 1, ect: '...'}
}, function(error) {
// Authentication failed...
});
});
My partial code:
main.js
var myApp = angular.module('mail_app', ['ngRoute', 'ngResource', 'Devise']);
myApp.config(function($routeProvider, $locationProvider, $httpProvider, AuthProvider) {
console.log("in router")
$locationProvider.html5Mode(true);
$httpProvider.defaults.headers.common['X-CSRF-Token'] =
$('meta[name=csrf-token]').attr('content');
$httpProvider.defaults.headers.common['ClientType'] = 'browser';
// Customise login
AuthProvider.loginMethod('POST');
AuthProvider.loginPath('/api/v1/users/login.json');
// Customise register
AuthProvider.registerMethod('POST');
AuthProvider.registerPath('/api/v1/users.json');
});
SessionsController.js
myApp.controller('SessionsController', ['$scope', 'Auth', '$http', function($scope, Auth, $http) {
console.log("in session controller")
console.log(Auth.isAuthenticated());
$scope.loginUser = function() {
console.log("in login")
var credentials = {
email: $scope.email,
password: $scope.password
};
Auth.login(credentials).then(function(user) {
$scope.authError = 'Success!';
console.log(user); // => {id: 1, ect: '...'}
Auth.currentUser = user;
}, function(error) {
$scope.authError = 'Authentication failed...';
});
};
$scope.registerUser = function(){
console.log("in register function")
var ncredentials = {
email: $scope.newEmail,
password: $scope.newPassword,
password_confirmation: $scope.newPasswordConfirmation
};
Auth.register(ncredentials).then(function(registeredUser) {
console.log(registeredUser); // => {id: 1, ect: '...'};
}, function(error) {
$scope.authError = 'Registration failed...';
});
};
$scope.getCurrentUser = function(){
Auth.currentUser().then(function(user) {
// User was logged in, or Devise returned
// previously authenticated session.
console.log(user); // => {id: 1, ect: '...'}
$scope.id = user.id;
}, function(error) {
// unauthenticated error
});
};
$scope.isUserAuthenticated = function(){
Auth.isAuthenticated();
};
}]);
First of all you need to understand how cookies and sessions work in Rails.
From this article:
Rails uses a CookieStore to handle sessions. What it means is that all
the informations needed to identify a user's session is sent to the
client and nothing is stored on the server. When a user sends a
request, the session's cookie is processed and validated so rails,
warden, devise, etc. can figure out who you are and instantiate the
correct user from the database.
What this means is that on every request, Rails will look up at the session cookie, decode it and get something like
cookie = {
"session_id": "Value",
"_csrf_token": "token",
"user_id": "1"
}
At that point Rails knows that the current user has id=1 and can make a sql query. (Like current_user = User.find(1)).
When a user is logged in, a cookie is created, when the user is logged out - the cookie is destroyed. If Rails doesn't find a cookie or the cookie doesn't have information about the current user, devise will assume that the user is not logged in (current_user is nil)
Even if you login through ajax (to be particular it is through the 'angular_devise' gem in your case) the cookie is created. It is not stored on the server, but in the browser. (This is why if you are logged in one browser, you are not automatically logged in another browser) As you pointed out the library doesn't keep information who is logged in, and this is because the information is stored in a cookie and the library cannot decode the cookie without help from the server.
This is why you will have to make a call to get the current user if the user refreshes the page. (Sorry)
The way to get the current_user is very simple. This is the cleanest solution I found.
# application_controller.rb
def me
render json: current_user
end
# routes.rb
get "me" => "application#me"
// main.js
// I am not familiar with angular_devise lib but you get the point:
// this method fetches from server when myApp is initialized (e.g. on page reload)
// and assigns the current_user so he/she can be used by the app
myApp.run(["AuthService", function(AuthService) {
AuthService.getUserFromServer();
}]);
If you have to load data specific to the user, you will have to load the user first and then the data. Needless to say you will have to use promises.
TL;DR: You will have to ask the server
I am open for questions and comments.
I guess your problem is the refresh. The angular-devise lib is probably assuming you are in a SPA (Singe Page Application) so it should not refresh. With this assumption, angular-devise can store all the information in memory. When you refresh your page, you basically bootstrap the application from zero. And the request to server is probably issued by your code when application is starting. You probably call Auth.currentUser() somewhere on start of the application
Had same problem. Just use that gem
https://github.com/jsanders/angular_rails_csrf
You can also get rid of "protect_from_forgery" in your application controller, but this is very risky.

Using a JSON user object for Authentication in AngularJS

So I've got an question about authentication and have been wondering how other people might handle this situation. I'm currently running an Angular app that is built on a Rails API.
So far for authentication I have a form that does a post to the Rails side which logs the user in and then sends them back to the Angular app on success. Once the cookie is set and the user is logged in, I'm able to access a user.json file which contains all the User information one might expect (Id, username, roles, rights, etc). Since verification all happens on Rails, if the user logs out then this information is removed. So the two states look like so...
Logged in
{
id: 99384,
name: "Username",
url: "//www.test.com/profiles/Username",
timezone: null,
rights: [ ],
roles: [
"admin"
],
}
Logged out
{
error: "You need to login or join before continuing."
}
So far I've seen all these millions of different ways to do auth for Angular, but it seems like nothing fits this type of method. So my question is, since the server is handling all of the verification, is there a way to just check if they user.json file is empty (displaying the error message) and if it is send the Angular app to the Rails login page? Is there really any point messing with Cookies, Tokens, etc when I can base it all on the JSON file?
You are already using cookies - the server is setting them. What you have done is a fairly standard way of doing things.
To check the json file, you can do something like this stub shows in your controller:
app.controller('AppControl', function($scope, $http, $location){
// Get the JSON file.
$http.get('/path/to/json/file')
.then(response){
if(response.data.error){
// redirect to login
$location.path('login');
}
else{
$scope.user = response.data;
// your app code here.
}
})
.catch(function (error){
// unable to reach the json file - handle this.
});
});
Of course, you should really move this out into a service so you can re-use it, and also cache the data, rather than getting the user every time you change route/page, but this gives you a vague idea.
EDIT Example factory:
.factory('User', function( $http ){
// Create a user object - this is ultimately what the factory will return.
// it's a singleton, so there will only ever by one instance of it.
var user = {};
// NOTE: I am assigning the "then" function of the login promise to
// "whenLoggedIn" - your controller code is then very easy to read.
user.whenLoggedIn = $http.get('user.json')
.then(function(response){
// Check to see if there is an error.
if (response.data.error !== undefined) {
// You could be more thorough with this check to determine the
// correct action (examine the error)
user.loggedIn = false;
}
else {
// the user is logged in
user.loggedIn = true;
user.details = response.data;
return user;
}
}).then; // <-- make sure you understand why that .then is there.
return user;
})
Usage in the controller
.controller('ExampleController', function($scope, User){
// It's handy to have the user on the scope - you can use it in your markup
// like I have with ng-show on index.html.
$scope.User = User;
// Do stuff only if the user is loggedin.
// See how neat this is because of the use of the .then function
User.whenLoggedIn( function (user){
console.log(user.details.name + " is logged in");
});
});
Because it's on the scope, we can do this in the html:
<body ng-controller="ExampleController">
<h1 ng-show="User.loggedIn == null">Logging in..</h1>
<h1 ng-show="User.loggedIn == true">Logged in as {{ User.details.name }}</h1>
<h1 ng-show="User.loggedIn == false">Not logged in</h1>
</body>
Here is an example on plunker where this is working.
Note the following:
If the user is/was already logged in, when you inject the service in the future, it won't check the file again. You could create other methods on the service that would re-check the file, and also log the user out, back in, etc. I will leave that up to you.
There are other ways to do this - this is just one possible option!
This might be obvious, but it's always worth saying. You need to primarily handle authentication and security on the server side. The client side is just user experience, and makes sure the user doesn't see confusing or conflicting screens.

Resources