I'm using browser-like approach for adding a bug to Bugzilla.
I'm making a successful login. When I add the bug, I don't get error. I get status code OK. But, the response html contains this:
Bugzilla – Suspicious Action
"It looks like you didn't come from the right page (you have no valid token for the create_bug action while processing the 'post_bug.cgi' script). The reason could be one of:
You clicked the "Back" button of your web browser after having successfully submitted changes, which is generally not a good idea (but harmless).
You entered the URL in the address bar of your web browser directly, which should be safe.
You clicked on a URL which redirected you here without your consent, in which case this action is much more critical.
Are you sure you want to commit these changes anyway? This may result in unexpected and undesired results."
There is a confirm button.
When I do this by hand (not by code), I don't get the error page. Instead, I get response that everything went fine and I can get my bug's id. So, ahead in my code I'm using the id. However, because of the error I get, the id is an empty string. How to resolve this?
Can it be resolved by clicking on the confirm button by code?
You can use Bugzilla's REST API from your script.
Creation of a bug is documented here
Related
I am developing a simple application using ADF comes with basic CRUD operations (create, read, update, delete). In this case, as you can see, I have dragged a link to the 1st column which is highlighted in yellow.
So whenever I deploy it and click that, it is supposed to redirect me to the Edit page where client will allow to make commit:
I did make sure the Action of link is associated with the Edit page (as highlighted in yellow above). However, the link wouldn't redirect me anywhere, no response.This is the unbounded task flow:
Okay so I have found out the solution. Due to the default setting, the application will be deployed on IE and this message will prompt out. As you can see, the message is mentioning about browser's compatibility. My IE is version 11.6, I'm not sure what's the issue here since my IE is kinda latest version but this message still pops out and affects the redirect link from working. However, simply copy the application URL to Google Chrome and run should fix this issue. Hope this helps in future.
If the two pages in the Unbounded Task Flow, then Add WildCard Control Flow Rule
and connect the two pages with the WildCard.
Or you can use the Popup instead of opening a new page for edit
I'm new to Robot Framework and stuck with quite simple login web page test using SeleniumLibrary:
*** Test Cases ***
Valid Login
Open Browser To Login Page
Input Username admin
Input Password test
Submit Credentials
Dashboard Page Should Be Open
[Teardown] Close Browser
Most of the keywords are irrelevant to the question, except
Submit Credentials
Click Button login-button
Dashboard Page Should Be Open
Location Should Be ${DASHBOARD URL}
Title Should Be Dashboard
If I run this test, it will fail, because Location Should Be check is executed too early, while browser is still on the original login page. I found two solutions that work, but both seems to be conceptually wrong:
Use sleep
Submit Credentials
sleep ${DELAY}
Dashboard Page Should Be Open
In this case ${DELAY} should be quite big (e.g. 10s) to be sure that page is definitely loaded or it may fail anyway. Also, I've read that best practice is to avoid sleeps. And I can't use some Wait Until Page Contains, because I don't know, whether login page will be loaded again with some error message or Dashboard page loaded in success.
Use Form Submit instead of Click Button:
Submit Credentials
Submit Form login-form
The Form Submit works fine, but it's different from actually clicking a button, because button may have some onclick handler that would prevent submitting a form.
Using Wait Until Keyword Succeeds as suggested in some other threads doesn't seem to help, as Click Button succeeds right away.
You definitely should not use sleep since it introduces artificial delays that may make your whole suite slower than it needs to be. I personally also thing Wait until keyword succeeds should almost never be used. It litters the log with messages as it retries. Plus, I think it masks problems instead of fixing them.
The answer is to use one of the wait keywords. You say you can't use Wait Until Page Contains ""because I don't know, whether login page will be loaded again with some error message or Dashboard page loaded in success". I don't understand that reasoning.
Your application should be deterministic. That is, if you enter correct login credentials than you should be guaranteed that it will go to the dashboard page, and if you enter the wrong conditions you should see an error and/or be redirected back to the login page.
The point of the test is to verify those conditions. So, for a test that verifies whether you get the dashboard page or not, you should find an element on the dashboard page and wait for it to be visible after submitting the form. If it doesn't appear in the proper amount of time, your test should throw an error.
Personally I recommend using page objects. The library I wrote [1], for example, has a mechanism to wait for a page refresh, and assertions to verify you are on the page you think you should be on. You don't need to use my library though -- the core of the code is only a couple hundred lines of code, so it's easy to write your own.
[1] https://github.com/boakley/robotframework-pageobjectlibrary
I have the following code I execute in Chrome with Tampermonkey, which I use to login to digitalocean.com.
setTimeout (function() {
document.querySelector("input[type=submit]").click();
}, 3000);
For some reason, this code sometimes work and sometimes it doesn't: That is, sometimes I'm logged in and sometimes (most cases) I get DigitalOcean's 404 webpage.
My login details are already saved in local storage and appear on the form.
By principle, this problem can be reproduced by registering to DigitalOcean, installing Tampermonkey, and executing the code with it, with the match:
https://cloud.digitalocean.com/login*
Might something be missing to ensure human-like behavior in the eyes of the machine?
OK, it took some digging, but I see what's going on.
There is an authentication token in the form.
If the token is not what the server expects, it kicks you to a 404 error at https://cloud.digitalocean.com/sessions.
If your browser loads the login page from cache (usually because you got to it by clicking the "back" button in your browser) you'll be submitting an invalid token (the one you got back when the page was put in the cache).
Sometimes it's wrong for some other reason I haven't figured out.
To deal with the cache-loaded page issue
I'd edit your script check if the page was loaded from cache, and refresh the page instead of triggering the click event:
if (window.performance.navigation.type === 2)
{
location.reload();
} else {
document.querySelector("input[type=submit]").click();
}
The other issue is probably an issue with DigitalOcean's back-end
I'd recommend that you report the fact that their login page seems to occasionally get a bad authentication token, as the issue can intermittently be reproduced by clicking (with the mouse) on the "Log In" button of a freshly loaded copy of the page.
(I wouldn't mention the script or they'll blame it and then you'll be out of luck.)
In the mean-time
As a stop-gap until they fix their issue, you could make a new script matching https://cloud.digitalocean.com/sessions (it sends me to that page exactly, but add a * if it's needed) that sends you back if you came from the login page, and got a 404 error:
if (document.referrer.startsWith("https://cloud.digitalocean.com/login") && document.title.endsWith(" (404)"))
{
history.back();
}
Note that document.title.endsWith(" (404)") only works because the contents of their 404 page's <title> tag ends with (404).
It seems to be a bug in Tampermonkey as the reported behavior doesn't happen in Greasemonkey.
Anyway, 3D1T0R's answer provides an interesting workaround with the current situation (would thumb up if I could).
I am integrating phpList into my website. I initialized database.
I was able to integrate my website with phpList.
In admin panel whenever i try to do anything like delete member from subscriber list or change any setting for subscriber page. I am getting this error "The requested URL /index.php was not found on this server."
I know that this is the problem of path.
When user receives email it says to confirm click on this.
http://admin.ridesharebuddy.com/lists/?p=preferences&uid=TOKEN
When user clicks on this, it displays error page not found.
Because path should be something like this.
http://admin.ridesharebuddy.com/rideshare/lists/?p=preferences&uid=TOKEN
How can i change this path ?
So from what I see, you have 2 issues:
Firstly:
index.php is not being found.
This is generally because of a) an upload error, or b) missing directory traversals within the script (../../ etc..)
What we need to know is why index.php is not found, and why it is being called when you try to make a change
Secondly:
The link generated when the email is sent, is incorrect. This will just be a case of finding where the link is generated, and modifying it to generate a correct code.
If you could update the post with source for the files, then I may be able to help you further.
If you feel you can't do the above, then I suggest using a different, more mature (and better coded), mailing script for your site.
I'm playing with Salesforce's "Sites" functionality today for the first time, whereby I can expose Salesforce functionality to anonymous users via VisualForce. It's cool, but I'm seeing some weird timing behavior. I've been trying to figure it out, but it's a mystery, so I'll ask here?
When I save my changes to my VisualForce page, I would expect to see the changes right away. Or at least, when I do a "real" save (by hitting "Save"), versus a "Quick Save," which I assume is what happens when I'm using the developer toolbar to edit -- or actually hitting the "Quick Save" button in the main VisualForce section.
At any rate, I save it as much as I possibly can, and I'm able to see the right thing when I go to the VisualForce page itself (not using the force.com URL). But when I go to the force.com URL, I'm seeing an old version of a page. If it's just a matter of waiting long enough, that's one thing. But it's acting like I'm doing something wrong.
During development, it is very helpful to add a cache="false" parameter to the apex:page tag. This should solve the issue.
Reference page for apex:page has other optional parameters as well.