Skip to main content
added 88 characters in body
Source Link
Brock Adams
  • 13k
  • 5
  • 39
  • 64

There have been no reported changes to the API, officially for many years, (unofficially since January).

But, frankly that script's approach should have never worked. OAuth credentials are sent to:
    https://stackapps.com/a/7936#access_token=y6rVASxxxxxxxxxRO2R9Bg)) (for example)

But this is immediately 302 redirected to:
    https://stackapps.com/questions/7935/bulk-flag-comments/7936#7936

So the current script cannot see the access token. (Except maybe on a really bad network/system, but one shouldn't count on such things.)

Anyway, You should never OAuth redirect to a page that is not fully owned and controlled by yourself, and on your server -- unless it is the officially provided URL for client side OAuth.

For the Stack Exchange API, this URL is: https://stackoverflow.com/oauth/login_success.

See this answerthis answer on Meta Stack Exchange for framework code and an example of using authentication with a userscriptframework code and an example of using authentication with a userscript.



Not only is that brittle (as you have discovered), it can also be a major security risk, depending on the page chosen.

There have been no reported changes to the API, officially for many years, (unofficially since January).

But, frankly that script's approach should have never worked. OAuth credentials are sent to:
    https://stackapps.com/a/7936#access_token=y6rVASxxxxxxxxxRO2R9Bg)) (for example)

But this is immediately 302 redirected to:
    https://stackapps.com/questions/7935/bulk-flag-comments/7936#7936

So the current script cannot see the access token. (Except maybe on a really bad network/system, but one shouldn't count on such things.)

Anyway, You should never OAuth redirect to a page that is not fully owned and controlled by yourself, and on your server -- unless it is the officially provided URL for client side OAuth.

For the Stack Exchange API, this URL is: https://stackoverflow.com/oauth/login_success.

See this answer on Meta Stack Exchange for framework code and an example of using authentication with a userscript.



Not only is that brittle (as you have discovered), it can also be a major security risk, depending on the page chosen.

There have been no reported changes to the API, officially for many years, (unofficially since January).

But, frankly that script's approach should have never worked. OAuth credentials are sent to:
    https://stackapps.com/a/7936#access_token=y6rVASxxxxxxxxxRO2R9Bg)) (for example)

But this is immediately 302 redirected to:
    https://stackapps.com/questions/7935/bulk-flag-comments/7936#7936

So the current script cannot see the access token. (Except maybe on a really bad network/system, but one shouldn't count on such things.)

Anyway, You should never OAuth redirect to a page that is not fully owned and controlled by yourself, and on your server -- unless it is the officially provided URL for client side OAuth.

For the Stack Exchange API, this URL is: https://stackoverflow.com/oauth/login_success.

See this answer on Meta Stack Exchange for framework code and an example of using authentication with a userscript.



Not only is that brittle (as you have discovered), it can also be a major security risk, depending on the page chosen.

added 88 characters in body
Source Link
Brock Adams
  • 13k
  • 5
  • 39
  • 64

There have been no reported changes to the API, officially for many years, (unofficially since January).

But, frankly that script's approach should have never worked. OAuth credentials are sent to:
    https://stackapps.com/a/7936#access_token=y6rVASxxxxxxxxxRO2R9Bg)) (for example)

But this is immediately 302 redirected to:
    https://stackapps.com/questions/7935/bulk-flag-comments/7936#7936

So the current script cannot see the access token. (Except maybe on a really bad network/system, but one shouldn't count on such things.)

Anyway, You should never OAuth redirect to a page that is not fully owned and controlled by yourself, orand on your server -- unless it is the officially provided URL for client side OAuth.

For the Stack Exchange API, this URL is: https://stackoverflow.com/oauth/login_success.

See this answer on Meta Stack Exchange for framework code and an example of using authentication with a userscript.



Not only is that brittle (as you have discovered), it can also be a major security risk, depending on the page chosen.

There have been no reported changes to the API, officially for many years, (unofficially since January).

But, frankly that script's approach should have never worked. OAuth credentials are sent to:
    https://stackapps.com/a/7936#access_token=y6rVASxxxxxxxxxRO2R9Bg)) (for example)

But this is immediately 302 redirected to:
    https://stackapps.com/questions/7935/bulk-flag-comments/7936#7936

So the current script cannot see the access token.

Anyway, You should never OAuth redirect to a page that is not fully owned and controlled by yourself, or the officially provided URL for client side OAuth.

For the Stack Exchange API, this URL is: https://stackoverflow.com/oauth/login_success.

See this answer on Meta Stack Exchange for framework code and an example of using authentication with a userscript.



Not only is that brittle (as you have discovered), it can also be a major security risk, depending on the page chosen.

There have been no reported changes to the API, officially for many years, (unofficially since January).

But, frankly that script's approach should have never worked. OAuth credentials are sent to:
    https://stackapps.com/a/7936#access_token=y6rVASxxxxxxxxxRO2R9Bg)) (for example)

But this is immediately 302 redirected to:
    https://stackapps.com/questions/7935/bulk-flag-comments/7936#7936

So the current script cannot see the access token. (Except maybe on a really bad network/system, but one shouldn't count on such things.)

Anyway, You should never OAuth redirect to a page that is not fully owned and controlled by yourself, and on your server -- unless it is the officially provided URL for client side OAuth.

For the Stack Exchange API, this URL is: https://stackoverflow.com/oauth/login_success.

See this answer on Meta Stack Exchange for framework code and an example of using authentication with a userscript.



Not only is that brittle (as you have discovered), it can also be a major security risk, depending on the page chosen.

Source Link
Brock Adams
  • 13k
  • 5
  • 39
  • 64

There have been no reported changes to the API, officially for many years, (unofficially since January).

But, frankly that script's approach should have never worked. OAuth credentials are sent to:
    https://stackapps.com/a/7936#access_token=y6rVASxxxxxxxxxRO2R9Bg)) (for example)

But this is immediately 302 redirected to:
    https://stackapps.com/questions/7935/bulk-flag-comments/7936#7936

So the current script cannot see the access token.

Anyway, You should never OAuth redirect to a page that is not fully owned and controlled by yourself, or the officially provided URL for client side OAuth.

For the Stack Exchange API, this URL is: https://stackoverflow.com/oauth/login_success.

See this answer on Meta Stack Exchange for framework code and an example of using authentication with a userscript.



Not only is that brittle (as you have discovered), it can also be a major security risk, depending on the page chosen.