We are using GoPay.com for payments in our app. It runs in two modes, full redirect to their site or iframe based solution to show the payment form inline. The conditions for display either of those is not exactly clear and might vary per a browser and who knows what else.
I need to interact with the payment form in tests to go through with it, but I am struggling how to do that. There is a sandbox environment, so it's ok to do test (free) payments.
Basically, I tried the following, but Cypress is not waiting for that page to load and fails right away.
cy.window().then(win => {
if (win.location.host.includes('gopay.com')) {
return win.document.querySelector('.main-body')
} else {
return // find form in iframe somehow
}
})
Also, I am unsure how to tackle the finding that form in the iframe.
Related
I know it's a clickbait title, but this is a serious question. Recently, in Sri Lanka, the government deployed https://fuelpass.gov.lk/ application where a Sri Lankan can register and check the fuel available for the registered vehicle. (The system was designed to control the amount of fuel available to an individual as fuel imports have slowed down due to the economic crisis).
When I checked the system yesterday I realized that they have deployed the dev build to production. As I was going through the code, I noticed that in the Login component, there is a setTimeout call on the form submit to show a loading animation.
The login component looked something like this:
export default () => {
const [waiting, setWaiting] = useState(false)
return(
<Loading showLoading = {waiting}>
<form onSubmit = {() => {
setWaiting(true)
setTimeout(async () => {
await loginRequestCall()
setWaiting(false)
}, Math.floor(Math.random() * 5000)
}}>
<input />
<button>Send OTP</button>
</form>
</Loading>
)
}
Screenshot of the source code:
The important part is, when user clicks on the Send OTP, It shows the loading screen, only after waiting a random amount of time it sends the request.
I created a video about this and it kinda went viral in Sri Lanka. According to the comments, some of the justifications (for using setTimeout with a random amount of time to wait) were following.
It is a mechanism to prevent DDos attacks
Way to prevent users spamming Send OTP button causing multiple requests
It is a cheap way of load balancing (way to reduce the number of OTP requests)
I wouldn't think if someone wanted to DDos they would be dumb enough to use UI automation. There is no need of setTimeout to prevent spam also.
Which leave me with the last point.
So my questions are,
Is it possible to load balance using setTimeout?
If so, how exactly would it distribute the load?
Is there a valid reason to add a setTimout?
Is it possible to load balance using setTimeout?
Load balancing is the process of distributing network traffic across multiple servers.
Since load balancing is not reducing the number of calls but distributing them, it is not possible to do load balancing using setTimeout
If so, how exactly would it distribute the load?
As I mentioned, it is impossible to do so with setTimeout, at least not in a non-hacky and inefficient manner.
Is there a valid reason to add a setTimout?
In my opinion, this setTimeout might be intended to be used as a debounce function to avoid the user clicking on the OTP button multiple times if the feedback is not provided immediately (but still not doing the work since all calls will be done anyway).
So the answer is NO, in my opinion, there is not any valid reason for this setTimeout
I am trying to automate couple of pages using selenium web driver and node js . I was able to login , but after login I want to use same session initiated by web driver so that I can do automated testing on session protected page. This is my attempt
async function login(){
Let d = await new Builder()
.forBrowser('chrome')
.build();
await d.get('https://demo.textdomain.com/')
await d.findElement(By.id('username')).sendKeys('admin ')
await d.findElement(By.id('password')).sendKeys('admin');
await d.findElement(By.css('button[type="submit"]')).click();
d.getPageSource().then(function(content) {
if(content.indexOf('Welcome text') !==-1 ) {
console.log('Test passed');
console.log('landing page');
d.get('https://demo.textdomain.com/landingpage') //this is still going to login page as i cannot use the previous session
} else {
console.log('Test failed');
return false;
}
//driver.quit();
});
}
login();
Am I accidentally discarding the browser after login.
From a similar question on SQA StackExchange, you can store and restore the current session's cookies:
Using Javascript:
// Storing cookies:
driver.manage().getCookies().then(function (cookies) {
allCookies = cookies;
});
// Restoring cookies:
for (var key in allCookies) {
driver.manage().addCookie(key, allCookies[key]);
}
You might just be dealing with timing issues. Selenium moves very fast. Way faster than you can interact as a user. So it often acts in what seems like unpredictable ways. But that's only because Selenium is acting much faster than you would as a user. In order to work around this, you should make good use of Selenium's built-in driver.wait. For example:
const button = driver.wait(
until.elementLocated(By.id('my-button')),
20000
);
button.click();
The above waits until the button with id my-button is present in the DOM, and then clicks it. It will wait for a maximum of 20000 milliseconds, but will finish as soon as the button becomes available.
So in your case, if there is something that becomes available after the user is successfully logged in, you could wait on that element before going to the new page in your code.
As an aside, I'm also not so sure why you are using getPageSource()? That seems like a very heavy-handed way to get what you are looking for. Isn't that content inside an element you could get the contents of?
I wrote an article about How to write reliable browser tests using Selenium and Node.js which might help you understand in more detail the code example above from the article, along with other techniques you can use to wait reliably for a variety of conditions in the browser.
I believe your problem is not properly waiting for the login to complete.
Selenium doesn't wait for asynchronous actions to be done, it moves to the next line, so when you ask for the page source, there is a good chance the login action didn't complete on the server and the result is not what you expect it to be.
you have to explicitly tell Selenium to wait, so you need to add some code between the login and the code that checks if the user is login, for the sake of this assumption, add a 10 seconds timeout.
if this works for you, you wouldn't want to just waste time, so you need to wait for certain elements on the page to change because of the login, for example, you need to wait for the presence (or visibility if it is already in the DOM) of the user photo in the header.
also, I'm not sure how the "getPageSource" function behaves, it can use the existing page, or it can ask for a fresh copy.
I would advise you to use other ways to test if the user is logged in, by inspecting the DOM.
I suggest to re-use the session-cookie after first login in other web-driver instances.
First store the cookie:
var cookieValue = firstWebDriver.Manage().Cookies.GetCookieNamed(name:"cookie_name");
Then you can pass it by to any WebDriver instance, set it and drive the web-app as it would be the same user with different browser instances:
anotherWebDriver.Manage().Cookies.AddCookie(new Cookie(name:"cookie_name", value:cookieValue));
If you want to use the same browser instance, you have to synchronize them, because WebDriver invocations are in general not thread-safe and would probalby often lead to exceptions (e.g. stale because an element was changed or notfound, because one web-driver navigated to a different page).
Then I suggest to just use the window handle for the next instance, without caring about the session. The first one opens and the last one closes the session (count the referenced handles) and be sure only one driver uses this handle at a time. You can also create new browser windows and this will keep the session and give you a new handle:
var handle = firstWebDriver.CurrentWindowHandle;
otherWebDriver.SwitchTo().Window(handle);
I wrote the code in C# but should be easily adaptable to JavaScript.
I am not really a web app developer and I would like to ask about best practices for gating website content.
I am preparing to deploy documentation created with mkdocs. It uses Netlify Identity because with that Github auth is available without any coding.
My current solution: I have added the Netlify Identity script in head and the login/logoff button via template addons in mkdocs, and then created a static document /login/ (that gets picked up automatically in mkdocs but does not get generated with template).
In the standard template there is a JS redirect to /login/ unless user is logged in:
if (window.netlifyIdentity) {
window.netlifyIdentity.on("init", user => {
if (!user) {
document.location.href = "/login/";
}
});
}
On the static page there is a redirect to / only just after user has logged in:
if (window.netlifyIdentity) {
window.netlifyIdentity.on("init", user => {
if (!user) {
window.netlifyIdentity.on("login", () => {
document.location.href = "/";
});
}
});
}
I hope this is a reasonable way to go about it. The docs do not store anything critical but I still wouldn't want that content exposed.
But I have noticed on slow connection the redirect takes a second or two so when a deep URL is accessed the content flashes on the screen before login.
What can be done to stop this and load the content only after the login check is performed?
This is not going to work as you desire and is not secure.
If I wanted to read your content without an account, I could simply disable JavaScript in my browser (a few mouse clicks) and your site would load, but the redirect would never run.
Regardless, with JavaScript enabled, the way it works is that the browser downloads the page, then downloads any resources (including scripts), and then finally runs any scripts. There is no way to change that. Of course, on a fast system, the user may not perceive a delay, as the delay is very short, but there is always a delay. That is how browsers work.
If you don't want your users to have access to the information until after they are logged in , then you must not send the information out until they are logged in. In other words, you need to configure your server to not send the page at all until it receives verification that the user has permission to receive that information. How you do that depends on which server you are using among other things, which would be the subject of a separate question.
I know this is a old post but you can use netlify functions combined with a netlify redirect file.
You would have to set a role of a user when signing up using the metadata, you could do this with a netlify function thats hooked into netlify identity, more here.
Create a function called identity-signup.js when a user signs up this function is automatically called.
exports.handler = async (event) => {
const { user } = JSON.parse(event.body)
// you could do something with the user here: eg console.log(user.email)
// or using stripe: const customer = await stripe.customers.create({ email: user.email });
return {
statusCode: 200,
body: JSON.stringify({
app_metadata: {
roles: ['free']
}
})
}
}
Once you have a role you can simply create a _redirects file like so:
/authedcontent/* 200! Role=free
/authedcontent/ / 404
Later down the line you can extend the netlify function to save the users detail in an external database or maybe setup a stripe subscription.
The only caveat is that this requires a paid netlify account.
This may not actually be an issue with Identity Server or the oidc-client, but I am having trouble pinning down the problem. I am running this through System.js in an Aurelia application, so it's possible the issue originates from one of these external libraries.
In CheckSessionIFrame.start(session_state), we have the following code:
this._timer = window.setInterval(() => {
this._frame.contentWindow.postMessage(this._client_id + " " + this._session_state, this._frame_origin);
}, this._interval);
The first time the interval fires, there appear to be no problems. The iFrame's contentWindow exists (as expected) and the postMessage method is called without issue. Two seconds later, when the interval fires again, this._frame.contentWindow is undefined - so my best guess is the iFrame is dying somehow. Again, this may not be an issue with oidc-client, but I'm looking for any helpful guidance on what could cause this iFrame to die (perhaps internally it could be dying on a script?) such as a missing necessary config value for oidc-client.
For oidc-client to work with silent renew, you need to have your aurelia-app on an element that is not the body, so you can place elements within the body yet outside of your aurelia-app.
This allows you to put the IFrame outside of the aurelia-app, which prevents the Aurelia bootstrapper from eating it and lets oidc-client function independently of Aurelia.
EDIT
Based on your comment, and a little memory refreshing on my part, I rephrase/clarify:
The session checker and the silent renew functions work independently of each other. You can silent renew before the session checker has started with a manual call. You can also start the session checker without doing any silent renew. They are just convenient to use together, but that's their only relationship.
I'm assuming you use the hybrid flow and have the standard session checker implementation with an RP and OP iframe, where the OP iframe is in a check_session.html page and the RP iframe is somewhere in your aurelia app. In one of my projects I have the RP iframe in the index.html, outside of the aurelia-app element so it works independently of aurelia. But I guess it doesn't necessarily have to be there.
The session checker starts when you set the src property of the RP iframe to the location of your check_session.html with the session_state, check_session_iframe and client_id after the hash.
The check_session.html page will respond to that by starting the periodic polling and post a message back to the window of your aurelia app if the state has changed.
From your aurelia app, you listen to that message and do the signinSilent() call if it indicates a changed state. And from the silent_renew.html page, you respond to that with signinSilentCallback()
All that being in place, it really doesn't matter when you start the session checker. Tuck it away in a feature somewhere and load that feature last.
The only two things you need to worry about during the startup of your application is:
Check for window.hash starting with #code and call signinRedirectCallback(code) if it does
If it does not, just call signinSilent() right away (that leaves you with the least amount of things to check)
And then after either of those have been done, do getUser() and check if it's null or if the expired property === true. If either of those is the case, do the signinRedirect(). If not, your user is authenticated and you can let the aurelia app do it's thing and start the session checker etc.
I would definitely not put the initial authentication checks on your index.html within the aurelia-app. Because if aurelia happens to finish loading before the oidc checks are done, the process will fail. You also probably want to store the user object (and UserManager) in some cache/service/other type of singleton class so you can easily interact with oidc from your aurelia application.
I have a Facebook Connect site using the Javascript API - I'm not using any FBML tags. It was working fine until a couple of days ago and now I have a problem with reloading the page while the user is logged in.
The user can log in fine, and I can get the user's Facebook ID. They can refresh the page and they're still logged in (and I still get the ID). But if they refresh the page again (and subsequently), then FB.Connect.get_loggedInUser() always returns 'None', rather than the Facebook ID, even though FB.Connect.get_status().waitUntilReady() has said they're logged in.
Here's my basic code... can anyone see anything wrong?
FB_RequireFeatures(['Api'], function() {
FB.init('MY_API_KEY', '/xd_receiver.htm', {});
FB.ensureInit(function() {
FB.Connect.get_status().waitUntilReady( function( status ) {
switch (status) {
case FB.ConnectState.connected:
FB.Connect.requireSession(function() {
if (FB.Connect.get_loggedInUser()) {
var uid = FB.Connect.get_loggedInUser();
// Some more stuff here with the user's ID, displaying info in the page, etc.
}
}
break;
case FB.ConnectState.appNotAuthorized:
case FB.ConnectState.userNotLoggedIn:
// Display FB Connect button in page.
}
});
});
});
Is there something wrong with that? I can't work out how to ensure I get the user's logged in ID. Many thanks.
So, after much testing with various apps and domains and... it seems there was some conflict going on between the JavaScript Facebook code and some pyFacebook code in the Django back-end. Some confusion between the sessions stuff (yet to be figured out) was causing Safari to throw errors. So, we don't know the solution, but the JavaScript code above should, on its own, work fine.