I need to run one before tag for specific scenario. How to do that?
So I have one scenario where I need to set up some request like user no.1. I have my one token getting from system based on provided username and password. This is all set up in before tag in hook file - code no.1
Then I need to run another before tag in hook file to get token as user no.2 different user and finish this task. code no.2
I am not able to differentiate it or my system still gets new token like to be always user no.1
code no.1 - it runs each time
Before(async () => {
const page = World.page;
const token = retrieveToken();
console.log('Using environment url: ' + EnvironmentVariables.URL);
await page.goto(EnvironmentVariables.URL + `/?access_token=${token}&expires_in=3600&token_type=bearer`);
await page.waitForSelector(SelectorUtils.nameSelector(NavigationComponent.searchClientInputName));
await waitForSpinnerToEnd();
});
code no.2 - here I am trying to use annotation with name of scenario but with no effect. I get token but when I look at console I see login details from code no.1
Before({tags: '#SubmitSRForReviewFinish'}, async () => {
const page = World.page;
const token = retrieveTokenLogin();
console.log('Using environment url: ' + EnvironmentVariables.URL);
await page.goto(EnvironmentVariables.URL + `/?access_token=${token}&expires_in=3600&token_type=bearer`);
await page.waitForSelector(SelectorUtils.nameSelector(NavigationComponent.searchClientInputName));
await waitForSpinnerToEnd();
});
I need to be able to run before tag only for specific scenario. How to do that? How to log with another scenarion as another user?
SOLVED:by myself
SOLUTION:this solution with annotation works but you need to remember that if you have some beforeAll tag where you set up window and other properties once at the beginning you need to change it to only before tag cause your browser window is still open and no matter what it still gets old values.
Related
I have an existing Sails V1 project that was generated as an empty app (it uses a React front-end). I'd now like to add in the auth endpoints that would have been created if the app had been generated as a web app. Is that possible?
Yes, it is possible.
You need to hook up the policies and related actions. Your best bet, I would say, is to generate a new project, with the front-end included, and see how that is set up. It utilizes the policy-middleware to call the policy-actions.
module.exports.policies = {
'*': 'is-logged-in',
// Bypass the `is-logged-in` policy for:
'entrance/*': true,
'account/logout': true,
'view-homepage-or-redirect': true,
'deliver-contact-form-message': true,
};
Here you see that the policy.js in the /config folder, calls is-logged-in for all controllers by default. You also see that there is some exceptions added below.
is-logged-in is the file /api/policies/is-logged-in.js:
module.exports = async function (req, res, proceed) {
// If `req.me` is set, then we know that this request originated
// from a logged-in user.
if (req.me) {
return proceed();
}
// Otherwise, this request did not come from a logged-in user.
return res.unauthorized();
};
This is the part that does the check for the logged-in status of the user. You can see that it uses the req.me part, which is set up in the api/hooks/custom/index.js. Here it loads the user from the database and makes the logged in users data available on the req object.
If you don't have, or want to use, this hook, you can exchange req.me with req.session.userId, assuming that you set the userId on the session-object on your login-handler. Example from Sails-code:
....
var userRecord = await User.findOne({
emailAddress: inputs.emailAddress.toLowerCase(),
});
// check user exist
....
// check password
....
//check remember-me
....
// Modify the active session instance.
this.req.session.userId = userRecord.id;
// Send success response (this is where the session actually gets persisted)
return exits.success();
....
I hope this gets you on the right path, at least in terms of where to dig deeper.
Basically, I'm using the accounts-base package on meteor and on meteor startup, I set up what template the server should use for the password recovery mail, email confirmation mail, etc.
For example, in my server/startup.js on meteor startup I do many things like :
Accounts.urls.verifyEmail = function (token) {
return Meteor.absoluteUrl(`verify-email/${token}`);
};
Accounts.emailTemplates.verifyEmail.html = function (user, url) {
return EmailService.render.email_verification(user, url);
};
The problem is that my app is hosted on multiple host names like company1.domain.com, company2.domain.com, company3.domain.com and if a client wants to reset his password from company1.domain.com, the recovery url provided should be company1.domain.com/recovery.
If another client tried to connect on company2.domain.com, then the recovery url should be company2.domain.com.
From my understanding, this is not really achievable because the method used by the Accounts Package is "Meteor.absoluteUrl()", which returns the server ROOT_URL variable (a single one for the server).
On the client-side, I do many things based on the window.location.href but I cannot seem, when trying to reset a password or when trying to confirm an email address, to send this url to the server.
I'm trying to find a way to dynamically generate the url depending on the host where the client is making the request from, but since the url is generated server-side, I cannot find an elegent way to do so. I'm thinking I could probably call a meteor server method right before trying to reset a password or create an account and dynamically set the ROOT_URL variable there, but that seems unsafe and risky because two people could easily try to reset in the same timeframe and potentially screw things up, or people could abuse it.
Isn't there any way to tell the server, from the client side, that the URL I want generated for the current email has to be the client current's location ? I would love to be able to override some functions from the account-base meteor package and achieve something like :
Accounts.urls.verifyEmail = function (token, clientHost) {
return `${clientHost}/verify-email/${token}`;
};
Accounts.emailTemplates.verifyEmail.html = function (user, url) {
return EmailService.render.email_verification(user, url);
};
But I'm not sure if that's possible, I don't have any real experience when it comes to overriding "behind the scene" functionalities from base packages, I like everything about what is happening EXCEPT that the url generated is always the same.
Okay so I managed to find a way to achieve what I was looking for, it's a bit hack-ish, but hey..
Basically, useraccounts has a feature where any hidden input in the register at-form will be added to the user profile. So I add an hidden field to store the user current location.
AccountsTemplates.addField({
_id: 'signup_location',
type: 'hidden',
});
When the template is rendered, I fill in this hidden input with jQuery.
Template.Register.onRendered(() => {
this.$('#at-field-signup_location').val(window.location.href);
});
And then, when I'm actually sending the emailVerification email, I can look up this value if it is available.
Accounts.urls.verifyEmail = function (token) {
return Meteor.absoluteUrl(`verify-email/${token}`);
};
Accounts.emailTemplates.verifyEmail.html = function (user, url) {
const signupLocation = user.profile.signup_location;
if (signupLocation) {
let newUrl = url.substring(url.indexOf('verify-email'));
newUrl = `${signupLocation}/${newUrl}`;
return EmailService.render.email_verification(user, newUrl);
}
return EmailService.render.email_verification(user, url);
};
So this fixes it for the signUp flow, I may use the a similar concept for resetPassword and resendVerificationUrl since the signupLocation is now in the user profile.
You should probably keep an array of every subdomains in your settings and keep the id of the corresponding one in the user profile, so if your domain changes in the future then the reference will still valid and consistent.
I have a Cucumber feature like this one:
#MainSuite
Scenario: Verify that user can login
Given I can see the login form
Then I set a username
And I set a password
And I click in Login button
Then I see the "wrong-password" message
I need to check that the user can login in 5 different pages.
I need to run that feature in 5 different places.
It's like, I need to run that feature in /login.html, /old_login.html, /after_restore_password.html and more (it's just an example).
Do you know how to do it?
Currently, I have only one file hardcoded. Obviously I need to change it.
this.Given(/^I can see the login form$/, function(done) {
this.goTo('login.html');
browser.wait(EC.visibilityOf(this.loginFormContainer));
done();
});
Create an object containing the different login pages that you can go to.
Include an if statement in your step def if there is any extra code that needs to be executed.
this.Given(/^I can see the "(.*)" login form$/, function(loginPage, done) {
var logins = {
login : "login.html",
afterpasswordreset: "after-password-reset.html"
}
loginPage = loginPage.toLowerCase().replace(" ", "");
this.goTo(logins[loginPage]);
browser.wait(EC.visibilityOf(this.loginFormContainer));
done();
});
Make either separate Scenarios or feature file for each variation of login, or simply create a Scenario Outline for them
EDIT
Here is how I would implement the Scenario Outline:
#MainSuite
Scenario Outline: Verify that user can login
Given I can see the "<loginType>" login form
And I set a username
And I set a password
When I click in Login button
Then I see the "wrong-password" message
Examples:
| loginType |
| Login |
| After Password Reset |
I've been working with Sails since couple of weeks ago, I came from Rails and I don't have any experience working with Node.js.
Now I'm trying to make a robust token authentication using jsonwebtoken.
https://github.com/auth0/node-jsonwebtoken
I followed this guide http://thesabbir.com/how-to-use-json-web-token-authentication-with-sails-js/ and everything worked fine.
I'm able to make a sign up, sign in and then use the token correctly for different actions.
Now, there are some actions where I'd like to use the login user,
something like devise current_user helper.
For example, when creating a comment, this comment should belongs to the current user.
Using Sabbir Ahmed guide, in the line 33 from the isAuthorized.js policy the token gets decrypted so I can get the current user id from there.
So, my question is, what should be the best way to get the current user and be able to use it later in some controller?
For example I tried something like:
# isAuthorized.js line 34, after getting decrypted token
User.findOne({id: token.id}).exec(function findOneCB(err, found){
currentUser = found;
});
But, on this way, because this is an async action I can't use this currentUser in a controller.
I want to store the current user in order to be able to use it later in some controller without repeated the same code in each controller, something like a helper or maybe a service.
The trick is where you place the next(). Since you are making an async call, the control should only be transferred to next policy/ controller once the database action is competed.
You should modify the policy to:
User.findOne({id: token.id}).exec(function findOneCB(err, found){
if(err) next(err);
req.currentUser = found;
next();
});
And you should be able to access the user details in controllers that use isAuthorized policy via req.currentUser
If by
For example, when creating a comment, this comment should belongs to the current user.
what you mean is certain attributes like username, and country etc, rather than querying the database after verification, what you can choose to do is to send these additional attributes to jwToken.issue in api/controllers/UsersController.js
eg.
jwToken.issue({
id: user.id,
username: user.name,
country: user.country
})
How that helps is, you can keep api/policies/isAuthorized.js as is, and in all the controllers that you use in the future, you can access the payload values from as
token.username or token.country
Instead of having to query the database again, thereby saving you valuable response time.
Beware however, of the data you choose to send in the token (you could also send {user:user} if you want to) however, as the secret key or hashing is not required to decrypt the payload as you can figure # jwt.io , you might want to exercise restraint.
I have a Web API app, initialized thusly:
app.UseCookieAuthentication();
app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
app.UseOAuthBearerTokens(OAuthOptions);
app.UseGoogleAuthentication();
For calls to most controllers, it works great. However, it also requires a bit of javascript before client-side service calls are made:
function getSecurityHeaders() {
var accessToken = sessionStorage["accessToken"] || localStorage["accessToken"];
if (accessToken) {
return { "Authorization": "Bearer " + accessToken };
}
return {};
}
The problem is that we have a certain type of controller (one that accesses files) where no javascript can be run during the call. For example, the call might be to:
http://mysite/mycontroller/file/filename.jpg
...where the value is assigned as the src attribute of an img tag. The call works, but Thread.CurrentPrincipal.Identity is unauthenticated with a null name, so there's currently not a way to enforce security.
I'm new to Web API, so it may be a dumb question, but what's the way around this? What switches do I need to flip to not require javascript to add security headers? I was considering trying to find a way to force an authorization header in an IAuthorizationFilter or something, but I'm not even sure that would work.
So I figured out the solution to my problem.
First, I needed to configure the app to use an authentication type of external cookies thusly:
//the line below is the one I needed to change
app.UseCookieAuthentication(AuthenticationType = DefaultAuthenticationTypes.ExternalCookie);
app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
app.UseOAuthBearerTokens(OAuthOptions);
app.UseGoogleAuthentication();
Second, it turned out there was a line of code in my WebApiConfig file that was disabling reading the external cookie:
//this line needed to be removed
//config.SuppressDefaultHostAuthentication();
After that, I could see the external cookie from Google, which passed along an email address I could identify the user with.