Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
Post History
Unfortunately, it doesn't look like Greasemonkey will let you do this, at least not directly. Per GreaseSpot's description of @run-at document-start, that value maps to when document.readyState ==...
Answer
#4: Post edited
by
Canina
·
2022-10-06T13:31:37Z (about 2 years ago)
- Unfortunately, **it doesn't look like Greasemonkey will let** you do this, at least not directly.
- Per [GreaseSpot's description of `@run-at document-start`](https://wiki.greasespot.net/Metadata_Block#@run-at), that value maps to when `document.readyState == 'loading'`. [Per MDN](https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState), this maps to that "the [`document`](https://developer.mozilla.org/en-US/docs/Web/API/Document) is still loading".
- As far as I can tell from a quick perusal of MDN, this would seem to map to that *the request has already been sent* and thus the set of cookies to be sent along with that request has already been committed to.
- That also maps to the behavior you are seeing: the [cookie](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie) is added locally (as would be the case also if the server returned a [`Set-Cookie:` HTTP response header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie)) but the newly set cookie is sent to the web server only in *subsequent* requests.
- You would need to use something that can modify a HTTP request *before* it is actually sent to the remote web server. **It doesn't look to me like Greasemonkey offers a hook that fires that early.**
- ---
I'm assuming that the web site in question sets the cookie as a non-persisted session cookie, but if it does set it to be persisted and your cookie deletion settings are responsible for deleting it, you could perhaps just **add a cookie exception in the Privacy & Security section** of the browser preferences to "allow" cookies for the site.- ---
- Another possibility would be to **make your userscript automatically trigger a reload** of the web page after setting the cookie *if* the cookie wasn't there previously. Doing so would likely cause the login page to flash by temporarily, but it would cause you to be logged in automatically. In that case you probably want to use [`@run-at`](https://wiki.greasespot.net/Metadata_Block#@run-at) `document-idle` or maybe `document-end` instead of `document-start`. If you go this route, be careful so that your userscript doesn't end up in an infinite loop that you can't get it out of.
- ---
- The cleanest approach would probably be to **write a simple custom WebExtension add-on** that [intercepts web requests](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Intercept_HTTP_requests) for [the specific host](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions) and [modifies the request](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onBeforeSendHeaders) to [add the appropriate cookie](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Work_with_the_Cookies_API) as needed. Without having looked at writing Firefox extensions, I doubt that this would be significantly more involved than the Greasemonkey userscript you show in your question.
Doing so should enable you to set the cookie before the initial request is sent to the server by your browser, making it appear to the server from the beginning that you already have logged in. It would also likely work better than the force-reload alternative if the site modifies how the log in process works; in such a case, what your plugin does would simply look to the server like a stray cookie, and you would be presented with a login page as normal.
- Unfortunately, **it doesn't look like Greasemonkey will let** you do this, at least not directly.
- Per [GreaseSpot's description of `@run-at document-start`](https://wiki.greasespot.net/Metadata_Block#@run-at), that value maps to when `document.readyState == 'loading'`. [Per MDN](https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState), this maps to that "the [`document`](https://developer.mozilla.org/en-US/docs/Web/API/Document) is still loading".
- As far as I can tell from a quick perusal of MDN, this would seem to map to that *the request has already been sent* and thus the set of cookies to be sent along with that request has already been committed to.
- That also maps to the behavior you are seeing: the [cookie](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie) is added locally (as would be the case also if the server returned a [`Set-Cookie:` HTTP response header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie)) but the newly set cookie is sent to the web server only in *subsequent* requests.
- You would need to use something that can modify a HTTP request *before* it is actually sent to the remote web server. **It doesn't look to me like Greasemonkey offers a hook that fires that early.**
- ---
- I'm assuming that the web site in question sets the cookie as a non-persisted session cookie, but if it does set it to be persisted and your cookie deletion settings are responsible for deleting it, you could perhaps just **add a cookie exception in the Privacy & Security section** of the browser preferences to "allow" cookies for the site. Maybe you could use a Greasemonkey script to modify the cookie, changing it from a session cookie to a persisted cookie?
- ---
- Another possibility would be to **make your userscript automatically trigger a reload** of the web page after setting the cookie *if* the cookie wasn't there previously. Doing so would likely cause the login page to flash by temporarily, but it would cause you to be logged in automatically. In that case you probably want to use [`@run-at`](https://wiki.greasespot.net/Metadata_Block#@run-at) `document-idle` or maybe `document-end` instead of `document-start`. If you go this route, be careful so that your userscript doesn't end up in an infinite loop that you can't get it out of.
- ---
- The cleanest approach would probably be to **write a simple custom WebExtension add-on** that [intercepts web requests](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Intercept_HTTP_requests) for [the specific host](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions) and [modifies the request](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onBeforeSendHeaders) to [add the appropriate cookie](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Work_with_the_Cookies_API) as needed. Without having looked at writing Firefox extensions, I doubt that this would be significantly more involved than the Greasemonkey userscript you show in your question.
- Doing so should enable you to set the cookie before the initial request is sent to the server by your browser, making it appear to the server from the beginning that you already have logged in. It would also likely work better than the force-reload alternative if the site modifies how the log in process works; in such a case, what your plugin does would simply look to the server like a stray cookie, and you would be presented with a login page as normal.
- ---
- For the ultimate in "hacky" solutions, it might even be possible to write a **bookmarklet** that loads something (anything) from the host in question; modifies the set of cookies for the host; and then makes the request that actually brings up the logged-in content. Whether this can even work probably depends heavily on the interaction between the different origins involved. If it works, it would have the benefit of leaving you with an obvious "escape hatch" of simply navigating normally to the login page and logging in manually, should the automation break at some point.
#3: Post edited
by
Canina
·
2022-10-06T13:17:15Z (about 2 years ago)
- Unfortunately, **it doesn't look like Greasemonkey will let** you do this, at least not directly.
- Per [GreaseSpot's description of `@run-at document-start`](https://wiki.greasespot.net/Metadata_Block#@run-at), that value maps to when `document.readyState == 'loading'`. [Per MDN](https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState), this maps to that "the [`document`](https://developer.mozilla.org/en-US/docs/Web/API/Document) is still loading".
- As far as I can tell from a quick perusal of MDN, this would seem to map to that *the request has already been sent* and thus the set of cookies to be sent along with that request has already been committed to.
- That also maps to the behavior you are seeing: the [cookie](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie) is added locally (as would be the case also if the server returned a [`Set-Cookie:` HTTP response header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie)) but the newly set cookie is sent to the web server only in *subsequent* requests.
- You would need to use something that can modify a HTTP request *before* it is actually sent to the remote web server. **It doesn't look to me like Greasemonkey offers a hook that fires that early.**
- ---
- I'm assuming that the web site in question sets the cookie as a non-persisted session cookie, but if it does set it to be persisted and your cookie deletion settings are responsible for deleting it, you could perhaps just **add a cookie exception in the Privacy & Security section** of the browser preferences to "allow" cookies for the site.
- ---
Another possibility would be to **make your userscript automatically trigger a reload** of the web page after setting the cookie *if* the cookie wasn't there previously. Doing so would likely cause the login page to flash by temporarily, but it would cause you to be logged in automatically.- ---
- The cleanest approach would probably be to **write a simple custom WebExtension add-on** that [intercepts web requests](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Intercept_HTTP_requests) for [the specific host](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions) and [modifies the request](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onBeforeSendHeaders) to [add the appropriate cookie](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Work_with_the_Cookies_API) as needed. Without having looked at writing Firefox extensions, I doubt that this would be significantly more involved than the Greasemonkey userscript you show in your question.
- Doing so should enable you to set the cookie before the initial request is sent to the server by your browser, making it appear to the server from the beginning that you already have logged in. It would also likely work better than the force-reload alternative if the site modifies how the log in process works; in such a case, what your plugin does would simply look to the server like a stray cookie, and you would be presented with a login page as normal.
- Unfortunately, **it doesn't look like Greasemonkey will let** you do this, at least not directly.
- Per [GreaseSpot's description of `@run-at document-start`](https://wiki.greasespot.net/Metadata_Block#@run-at), that value maps to when `document.readyState == 'loading'`. [Per MDN](https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState), this maps to that "the [`document`](https://developer.mozilla.org/en-US/docs/Web/API/Document) is still loading".
- As far as I can tell from a quick perusal of MDN, this would seem to map to that *the request has already been sent* and thus the set of cookies to be sent along with that request has already been committed to.
- That also maps to the behavior you are seeing: the [cookie](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie) is added locally (as would be the case also if the server returned a [`Set-Cookie:` HTTP response header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie)) but the newly set cookie is sent to the web server only in *subsequent* requests.
- You would need to use something that can modify a HTTP request *before* it is actually sent to the remote web server. **It doesn't look to me like Greasemonkey offers a hook that fires that early.**
- ---
- I'm assuming that the web site in question sets the cookie as a non-persisted session cookie, but if it does set it to be persisted and your cookie deletion settings are responsible for deleting it, you could perhaps just **add a cookie exception in the Privacy & Security section** of the browser preferences to "allow" cookies for the site.
- ---
- Another possibility would be to **make your userscript automatically trigger a reload** of the web page after setting the cookie *if* the cookie wasn't there previously. Doing so would likely cause the login page to flash by temporarily, but it would cause you to be logged in automatically. In that case you probably want to use [`@run-at`](https://wiki.greasespot.net/Metadata_Block#@run-at) `document-idle` or maybe `document-end` instead of `document-start`. If you go this route, be careful so that your userscript doesn't end up in an infinite loop that you can't get it out of.
- ---
- The cleanest approach would probably be to **write a simple custom WebExtension add-on** that [intercepts web requests](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Intercept_HTTP_requests) for [the specific host](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions) and [modifies the request](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onBeforeSendHeaders) to [add the appropriate cookie](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Work_with_the_Cookies_API) as needed. Without having looked at writing Firefox extensions, I doubt that this would be significantly more involved than the Greasemonkey userscript you show in your question.
- Doing so should enable you to set the cookie before the initial request is sent to the server by your browser, making it appear to the server from the beginning that you already have logged in. It would also likely work better than the force-reload alternative if the site modifies how the log in process works; in such a case, what your plugin does would simply look to the server like a stray cookie, and you would be presented with a login page as normal.
#2: Post edited
by
Canina
·
2022-10-06T13:08:08Z (about 2 years ago)
- Unfortunately, **it doesn't look like Greasemonkey will let** you do this, at least not directly.
- Per [GreaseSpot's description of `@run-at document-start`](https://wiki.greasespot.net/Metadata_Block#@run-at), that value maps to when `document.readyState == 'loading'`. [Per MDN](https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState), this maps to that "the [`document`](https://developer.mozilla.org/en-US/docs/Web/API/Document) is still loading".
- As far as I can tell from a quick perusal of MDN, this would seem to map to that *the request has already been sent* and thus the set of cookies to be sent along with that request has already been committed to.
- That also maps to the behavior you are seeing: the [cookie](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie) is added locally (as would be the case also if the server returned a [`Set-Cookie:` HTTP response header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie)) but the newly set cookie is sent to the web server only in *subsequent* requests.
- You would need to use something that can modify a HTTP request *before* it is actually sent to the remote web server. **It doesn't look to me like Greasemonkey offers a hook that fires that early.**
- ---
- I'm assuming that the web site in question sets the cookie as a non-persisted session cookie, but if it does set it to be persisted and your cookie deletion settings are responsible for deleting it, you could perhaps just **add a cookie exception in the Privacy & Security section** of the browser preferences to "allow" cookies for the site.
- ---
- Another possibility would be to **make your userscript automatically trigger a reload** of the web page after setting the cookie *if* the cookie wasn't there previously. Doing so would likely cause the login page to flash by temporarily, but it would cause you to be logged in automatically.
- ---
The cleanest approach would probably be to **write a simple custom WebExtension add-on** that [intercepts web requests](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Intercept_HTTP_requests) for [the specific host](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions) and [adds the appropriate cookie](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Work_with_the_Cookies_API) as needed. Without having looked at writing Firefox extensions, I doubt that this would be significantly more involved than the Greasemonkey userscript you show in your question.- Doing so should enable you to set the cookie before the initial request is sent to the server by your browser, making it appear to the server from the beginning that you already have logged in. It would also likely work better than the force-reload alternative if the site modifies how the log in process works; in such a case, what your plugin does would simply look to the server like a stray cookie, and you would be presented with a login page as normal.
- Unfortunately, **it doesn't look like Greasemonkey will let** you do this, at least not directly.
- Per [GreaseSpot's description of `@run-at document-start`](https://wiki.greasespot.net/Metadata_Block#@run-at), that value maps to when `document.readyState == 'loading'`. [Per MDN](https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState), this maps to that "the [`document`](https://developer.mozilla.org/en-US/docs/Web/API/Document) is still loading".
- As far as I can tell from a quick perusal of MDN, this would seem to map to that *the request has already been sent* and thus the set of cookies to be sent along with that request has already been committed to.
- That also maps to the behavior you are seeing: the [cookie](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie) is added locally (as would be the case also if the server returned a [`Set-Cookie:` HTTP response header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie)) but the newly set cookie is sent to the web server only in *subsequent* requests.
- You would need to use something that can modify a HTTP request *before* it is actually sent to the remote web server. **It doesn't look to me like Greasemonkey offers a hook that fires that early.**
- ---
- I'm assuming that the web site in question sets the cookie as a non-persisted session cookie, but if it does set it to be persisted and your cookie deletion settings are responsible for deleting it, you could perhaps just **add a cookie exception in the Privacy & Security section** of the browser preferences to "allow" cookies for the site.
- ---
- Another possibility would be to **make your userscript automatically trigger a reload** of the web page after setting the cookie *if* the cookie wasn't there previously. Doing so would likely cause the login page to flash by temporarily, but it would cause you to be logged in automatically.
- ---
- The cleanest approach would probably be to **write a simple custom WebExtension add-on** that [intercepts web requests](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Intercept_HTTP_requests) for [the specific host](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions) and [modifies the request](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onBeforeSendHeaders) to [add the appropriate cookie](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Work_with_the_Cookies_API) as needed. Without having looked at writing Firefox extensions, I doubt that this would be significantly more involved than the Greasemonkey userscript you show in your question.
- Doing so should enable you to set the cookie before the initial request is sent to the server by your browser, making it appear to the server from the beginning that you already have logged in. It would also likely work better than the force-reload alternative if the site modifies how the log in process works; in such a case, what your plugin does would simply look to the server like a stray cookie, and you would be presented with a login page as normal.
#1: Initial revision
by
Canina
·
2022-10-06T13:03:31Z (about 2 years ago)
Unfortunately, **it doesn't look like Greasemonkey will let** you do this, at least not directly. Per [GreaseSpot's description of `@run-at document-start`](https://wiki.greasespot.net/Metadata_Block#@run-at), that value maps to when `document.readyState == 'loading'`. [Per MDN](https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState), this maps to that "the [`document`](https://developer.mozilla.org/en-US/docs/Web/API/Document) is still loading". As far as I can tell from a quick perusal of MDN, this would seem to map to that *the request has already been sent* and thus the set of cookies to be sent along with that request has already been committed to. That also maps to the behavior you are seeing: the [cookie](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie) is added locally (as would be the case also if the server returned a [`Set-Cookie:` HTTP response header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie)) but the newly set cookie is sent to the web server only in *subsequent* requests. You would need to use something that can modify a HTTP request *before* it is actually sent to the remote web server. **It doesn't look to me like Greasemonkey offers a hook that fires that early.** --- I'm assuming that the web site in question sets the cookie as a non-persisted session cookie, but if it does set it to be persisted and your cookie deletion settings are responsible for deleting it, you could perhaps just **add a cookie exception in the Privacy & Security section** of the browser preferences to "allow" cookies for the site. --- Another possibility would be to **make your userscript automatically trigger a reload** of the web page after setting the cookie *if* the cookie wasn't there previously. Doing so would likely cause the login page to flash by temporarily, but it would cause you to be logged in automatically. --- The cleanest approach would probably be to **write a simple custom WebExtension add-on** that [intercepts web requests](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Intercept_HTTP_requests) for [the specific host](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions) and [adds the appropriate cookie](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Work_with_the_Cookies_API) as needed. Without having looked at writing Firefox extensions, I doubt that this would be significantly more involved than the Greasemonkey userscript you show in your question. Doing so should enable you to set the cookie before the initial request is sent to the server by your browser, making it appear to the server from the beginning that you already have logged in. It would also likely work better than the force-reload alternative if the site modifies how the log in process works; in such a case, what your plugin does would simply look to the server like a stray cookie, and you would be presented with a login page as normal.