Thegreatsuspender: Fails to preserve URLs as is

Created on 4 Jun 2018  路  6Comments  路  Source: greatsuspender/thegreatsuspender

It fails to preserve URLs as is. For instance, try suspending and unsuspending http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=PREFIX+foaf%3A+%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0D%0A%0D%0ASELECT+%3Fperson+%3Fname+where+%7B%0D%0A+++%3Fperson+foaf%3Aname+%3Fname+.%0D%0A%7D+LIMIT+100&format=text%2Fhtml&CXML_redir_for_subjs=121&CXML_redir_for_hrefs=&timeout=30000&debug=on&run=+Run+Query+.

Specifications:

  • Extension version: 7.0.85
  • Browser & version: Chrome 66.0.3359.181
  • Operating system & version: macOS Sierra 10.12.6
bug-confirmed waiting-on-release

Most helpful comment

Thanks for this.
I'll try to fix this asap.

All 6 comments

That's probably because of the uri= in the URL. Calling gsUtils.getHashVariable("uri", "blah#uri=http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=PREFIX+foaf%3A+%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0D%0A%0D%0ASELECT+%3Fperson+%3Fname+where+%7B%0D%0A+++%3Fperson+foaf%3Aname+%3Fname+.%0D%0A%7D+LIMIT+100&format=text%2Fhtml&CXML_redir_for_subjs=121&CXML_redir_for_hrefs=&timeout=30000&debug=on&run=+Run+Query+") returns "http://dbpedia.org/sparql?default-graph-". It doesn't look like the code handles a URL with a uri= substring already in it.

Interestingly, my QuicKey extension unsuspends that page to the correct URL. It assumes everything from the uri= to the end of the string is the unsuspended URL, which might be a bad assumption if TGS ever changes the hash format.

Let's make the great suspender great again...

@fwextensions Thanks for looking into this issue.
So, I guess it is just a matter of splitting hashStr into only two pieces based on the first occurrence of uri= here.

Right. Looks like changing that line to this would fix it:

valuesByKey.uri = hashStr.split('uri=').slice(1).join("");

That joins the split pieces back together, in case the uri gets split into multiple pieces. I changed it in an alpha build and it does seem to work.

But just slicing at the index of "uri=" might be a little more straightforward. Or matching with a regex, since one's used to pull out the # anyway, something like this:

var match = urlStr.match(/^[^#]+#(.*?)&?uri=(.+)$/);

if (!match) {
    return false;
}

hashStr = match[1];
valuesByKey.uri = match[2];

And using a new URLSearchParams() to parse the key/values would probably be a little safer than just splitting on &.

Anyway, it looks like assuming uri is the very last parameter is a safe assumption since it has to be, given that it's not URI-encoded. Otherwise, any params in the URI would get mixed in with TGS's.

Thanks for this.
I'll try to fix this asap.

I have pushed a fix for this (https://github.com/deanoemcke/thegreatsuspender/commit/40ce23f97562392355cfc6f30221dfe42a8deb77)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

minig0d picture minig0d  路  4Comments

codemedic picture codemedic  路  3Comments

hzhongmj picture hzhongmj  路  4Comments

ducc-coder picture ducc-coder  路  3Comments

philoupd picture philoupd  路  3Comments