I'm working on a chrome extension that will always have a current user who is logged in to GitHub. In order to switch users, I want to have a log out button in my extension that logs the current user out.
I've tried simply
chrome.windows.create({'url':'https://github.com/logout'})
Which takes me to the GitHub logout page but there is still a confirmation that the user would have to click on to successfully logout. I would like to be able to log the user out in the background or at a minimum, without them having to click on an additional confirmation.
Any thoughts?
You can check if one of the two techniques mentioned here works for you:
"How to automatically click a confirm box?": overriding the window.confirm function
"Auto Click for JavaScript confirm dialog": inserting dummy function showConfirm() at the top of the header of the Browser.Document which overwrites/suppress the original function showConfirm().
Even if the names of the methods differ in the Github confirmation page, the idea remains: if you can somehow override/silence the confirmation method, you can skip past that step.
Working Solution
When I called https://github.com/logout from an external page it showed a form with a submit/confirm button to logout. The form doesn't have an id or class but I managed to submit it using
document.getElementsByTagName('form')[1].submit();
Of course, this isn't ideal since it will break if github changes the layout of their logout page. Also, there is a delay between when the page is loaded and the form is submitted which isn't very user friendly. I'll update here if I find a better solution
Related
This annoying message pops up every time you try to refresh the page that you have already added the product on that page to the cart and also when you fail to save changes in user account details and try to refresh the page.
I've already read the solutions about this problem in other similar questions like:
Change your request type from POST to GET
Change the request type for reloading the page from window.location.reload(); to window.location=window.location;
Redirect users to another page
which seems like such changes should be made directly on Firefox (which is not what I want) except for redirecting users to the shopping cart (which I'm not thinking at this point unless there is no any other solutions)
I want to fix the problem for every WooCommerce user who browses the store using Firefox. so is there any way (other than redirecting) to prevent WooCommerce from triggering this warning message in Firefox?
I have a form, with a code to show a popup when I press a create/edit link. Now when I do a page refresh, I get the following popup
I have managed to stop the popup from appearing when Retry is pressed, by handling it on the code behind of my aspx, but when Cancel is pressed, the page blinks (I guess it renders again?) and the popup is shown.
It doesn't go back to the server. It just goes to the javascript function that displays the popup, and shows it.
It should be noted at this point that this popup is just a <div> which can be shown or hidden.The default property of this <div> is hidden.
Please help me solve this issue and also explain why this is happening. I haven't been able to find anything on the internet explaining this issue.
When submitting a form, content may be sent with either POST or GET.
Sending with GET appends values to the address defining what webpage you are on. It could look like this:
www.domain.tld/page?value1=apple&value2=banana
Sending with POST sends the value in a hidden field that the server receives.
Clicking "Retry" will load the website with the information currently held within the POST field. Clicking cancel should display the address you are heading to without the POST content.
I hope this answers your question. If not, is there any way for you to show the piece of code that handles the POST data?
The browser saves the data in the form when you submit it, and when you refresh the page, the browser attempts to send this data again. The popup is a warning from the browser that this is about to happen, which is important since the form could be on a shopping site, so resending the data would result in accidentally buying the same things multiple times.
To fix this, you can redirect to another page once the form has been submitted, or you can add code to reset the form so the data won't be sent again.
We should follow a best practice to solve this problem. Better have a look at this. When you press the cancel button, it simply load the previous page and values will be persisted.
My understanding so far is that when you press the cancel button, the values for the page is taken from the browser's cache. I cleared the cache to test this theory. The cache isn't just storing the values of the page but also the last server response received. In my case, the last server response was to show the the popup by calling my javascript function, along with the required values, which is what it did.
Now my work around to it was to make the closing button as a server command as well, so that the final response would be to hide the popup.
Please do let me know if there is something wrong in this explanation.
I've searched for answers to this -- seems like all the answers relate to the old Facebook API so the solutions are no longer relevant.
The problem I'm having: I've got a custom Facebook tab which has a button on it that, when clicked, triggers FB.login(). The way it should work is: user clicks to log in, popup comes up to authorize the app, user clicks authorize, the popup closes. This flow works correctly on all browsers except IE8 and below. On IE8, the user clicks to log in, the popup comes up to authorize the app, the user clicks authorize, then the content INSIDE the popup refreshes with the content from the redirect URL. Needless to say, this is not the desired experience for IE8 users :(
I've tried everything I could find: doublechecked that there are no javascript errors, ensured that there is a valid channel file, etc. Nothing appears to fix it. Everything is happening through secure (https), so I'm not sure if that has anything to do with it.
I've been trying to fix this for DAYS now; any help would be GREATLY appreciated!
Make sure fb-root element is only once in your page , I have faced this issues and when i made sure that fb-root div is only once the issue got resolved
You should specify a p3p header in all responses from your web server. Please see: http://www.hanselman.com/blog/TheImportanceOfP3PAndACompactPrivacyPolicy.aspx.
By "the content INSIDE the popup refreshes with the content from the redirect URL" do you mean that you are passing a redirect URL? If so, don't do that. The popups work using some cross-domain JavaScript magic with a specially constructed redirect URL. If you put your own, then the popups may break.
Also, make sure you're setting a proper channelUrl when you call FB.init().
I have a page where navigation is handled by hiding and showing preloaded divs when users click on links. But, the users think they've actually changed pages, so they click on their browser's "back" button trying to go back to the div that was previously hidden. But of course, they go back to the page from which they came.
What's the best way to handle this? 90% of the traffic is from a login page. Should I just sandwich a redirect page in between the two? How is this done? Can I just change the browser's back button behavior?
If you are already using jQuery, why not simply add a history manager like jq-bbq or the hashchange or history manager? (Or, if you want to really go all out, switch to a MVC JavaScript framework like Sammy.) That way, the back button will work as the user expects, rather than hacking around their expectations by blocking the back button or throwing in redirects. (Unless you have a good reason to, of course :-) )
If you use a browser history plugin like the jQuery UI one you end up changing the history so that the back button doesn't actually unload the page.
http://yoursite.com
-> User clicks something
-> new address bar reads http://yoursite.com/#/something
because of the hash mark when user goes back it goes back to http://yoursite.com which should inturn fire your show previous div function
read more about the available history manager plugins available for jQuery. There are quite a few. Most if not all provide available callback functions that you can specify.
On change of the state of your page, write a unique set of parameters to the hash of your URL. You can change this via JS without causing the page to reload.
Set a timer on the page that checks the current location hash repeatedly, and if it changes (i.e. the user presses the Back button) then update the state of your page to match the URL.
I have this scheme working to great effect in a local application.
The jQuery Address library is another great alternative.
http://www.asual.com/jquery/address/
You can set the URL for different application states, and get the URL 'parameters' when the page reloads.
Two ideas:
1) onbeforeunload. Ask the user if they want to really go back.
2) Sandwidch a redirect page. Login -> redirect -> your page. A single back click would take the user to your redirect page.
The second is kind of a pain in the neck for people who know what they're doing though. I think the Back button (and all standard navigational elements) should be messed with as little as possible.
I would go with onbeforeunload:
function sure()
{
event.returnValue = "sure?";
}
...
<BODY onbeforeunload="sure()">
Am doing the online cab booking services,
once user reached the successfully completed his journey,
we are showing the thank for booking and we show the booking id, some people they hit the F5
key, so page get refresh and the new entry will inserted ,
So i want to deactivate F% on my cashthankyou you page,
Thanks
Bharanikumar
You won't have much luck with this - control / detection of key presses is heavily browser dependant, and overriding standard behaviour is usually impossible.
Rather than this approach, you need to detect and appropriately handle duplicate form submission:
How to handle multiple submissions server-side
The best option is usually to find a way that don't involves tampering with browser functionality. In your case, that would be making the user submit the booking to a page that inserts the entry, and then redirects the user to a thankyou-page that does nothing more than displaying that. The user would then be able to refresh the page any amount of times, without anything dangerous happening.
You can't. This is in how the browser is coded and you can't disable it from the webpage.
You need to restructure your application to identify a refresh of this kind and not creat an additional record.
One way to do that is to check if a record was entered for the user just several seconds ago and if that is the case, not insert a new record.
Another way it to add an interstitial page that will do the adding then redirect to your confirmation page (this page is just a display page and refreshing it won't do anything).
I dont't know if you can disable the F5 but can display some kind of "are you sure" message.
This can be done using window.onbeforeunload which is called before the window reloads or gets closed.
There could be a couple of reasons they refresh the page. Maye they used their back button, double-clicked on your submit button or anything else that does the loading twice.
Here are two real solutions to your problem:
1) Put in a form field with a random number, save this number along with the booking and then check against your booking table if there already are a booking with that value. This will stop them from sending the form twice.
2) Save a cookie with the last time they completed a booking. Check this value and don't allow a new booking for i.e. five minutes.
An alternative would be to redirect your user to the thank you page, loading the ID from the session.
This way, when the user hits F5 the thank you page will load and no form submission will be attempted again.
If no booking ID is in the session when the thank you page is loading, redirect back to the home page or a suitable error page.