The Un-Official Proxomitron Forum
sidki-config: Feb 13 2009 - Printable Version

+- The Un-Official Proxomitron Forum (https://www.prxbx.com/forums)
+-- Forum: Proxomitron Config Sets (/forumdisplay.php?fid=43)
+--- Forum: Sidki (/forumdisplay.php?fid=44)
+--- Thread: sidki-config: Feb 13 2009 (/showthread.php?tid=1261)

Pages: 1 2 3 4 5 6 7


RE: sidki-config: Feb 13 2009 - sidki3003 - Mar. 12, 2009 11:07 PM

(Mar. 12, 2009 09:32 PM)lnminente Wrote:  Just documenting to don't waste the time someone doing this in the future_________

Hi Sidki i was going to tell you about a modification i made to the url parser because i noticed in my log file with URLs like "http://mt3.google.com/mt/v=w2.92&hl=es&x=253383&y=205546&z=19&s=Galileo" it says the extension is "92&hl=es&x=253383&y=205546&z=19&s=Galileo".

I was considering "92" as something nearer to what we could understand as the extension so i replaced ([^?;#]+)\4$SET(uExt=\4)|) by ([^?;#&]+)\4$SET(uExt=\4)|) to make the work, buuuuuuut i now realized in windows we can use & as a character for our extensions. So we should forget this "fix"...

Thanks lnminente.

What's interesting, when i visit the URL you posted above, i get a document saying (color added by me):
Quote:The requested URL /mt?v=w2.92&hl=es&x=253383&y=205546&z=19&s=Galileo was not found on this server.

So the server script is interpreting the last slash as questionmark.

If that would be a common thing, we could modify the parser expression to consider everything after an equal sign, after the last slash, as query string. Or similar, or even simpler.

However, we would need a reasonable number of examples from different servers to get it right.

BTW, Firefox is parsing that URL similar to the current expression:
location.pathname -> "/mt/v=w2.92&hl=es&x=253383&y=205546&z=19&s=Galileo"
location.search -> ""


RE: sidki-config: Feb 13 2009 - lnminente - Mar. 13, 2009 12:32 AM

To menction the link i posted is the one wich request each of the images of google maps. I modified by hand to a high zoom, and in some areas we get the 404 error.

I have seem this behavior of the last slash in more places, but i think it's not very common. Here is another example not about extension, but where the last slash acting like a ? to do some redirections:
http://www.google.com/reader/public/javascript/feed/http://prxbx.com/forums/syndication.php?type=atom1.0
http://www.google.com/reader/public/javascript/feed/http://prxbx.com/forums/syndication.php

Sidki, I'm thinking in writing a filter wich would log to a file URLs with more than 150 chars. This could be helpful to be noticed about tracking and also get some strange slashes.
-filter already written Smile! -
Code:
[HTTP headers]
In = FALSE
Out = TRUE
Key = "URL :0_1.2 Log large URLs {ln}090312 TEST"
URL = "(^local.ptron)(*(;*)\3|*)"
Match = "(??????????)++{15,*}\w &$ADDLST(debug,I_1.2 Log large URLs\t$DTM(Y/M/D H:m:s't)\t$GET(uDom)\t$GET(uExt)\t$GET(ContentType)\t\u\t\9\t\1\t\3)"
Replace = "$LOG(!C$DTM(c),0_1.2 Log large URLs: \u) ($SET(0=\q\a)$TST((\0)=(?)+{2,*})$LOG(w    \0)|) ($TST((\3)=(?)+{2,*})$LOG(C    \3)|) "



RE: sidki-config: Feb 13 2009 - sidki3003 - Mar. 13, 2009 01:00 AM

Let us know if you find interesting URLs. Smile!
BTW, i don't see where you're setting \3 .


RE: sidki-config: Feb 13 2009 - lnminente - Mar. 13, 2009 01:10 AM

Fixed Wink and added loging to a list named debug, $GET(ContentType) can be replaced by the content of $IHDR(Content-Type:...)

Before you ask me \9 \1 \3 in the logging file, is a standard method i use for logging Wink


RE: sidki-config: Feb 13 2009 - sidki3003 - Mar. 13, 2009 01:16 AM

Does the \3 that you've assigned in the URL match survive till the Match/Replace? Usually it doesn't.


RE: sidki-config: Feb 13 2009 - lnminente - Mar. 13, 2009 01:26 AM

mmm i think you are right. It comes from my firsts header filters a few months ago, and was working before i changed it for using the "URL :" format. I will try tomorrow moving that code to the match area. Thanks for advicing that Wink


RE: sidki-config: Feb 13 2009 - lnminente - Mar. 13, 2009 12:23 PM

Updated. Now works config independant and moved to input filters, to get the Content-type var. Test here
Code:
[HTTP headers]
In = TRUE
Out = FALSE
Key = "URL :I_1.6 Log large URLs {ln}090313b"
URL = "(^local.ptron)"
Match = "(??????????)++{15,*}\w &$URL([^;]+\3) $IHDR(Content-Type:  (\0;*|\0))$SET(ContentType=\0) $ADDLST(debug,I_1.6 Log large URLs\t$DTM(Y/M/D H:m:s't)\t$GET(uDom)\t$GET(uExt)\t$GET(ContentType)\t\u)"
Replace = "$LOG(!C$DTM(c),I_1.6 Log large URLs: \u) ($SET(0=\q\a)$TST((\0)=??*)$LOG(w    \0)|) ($TST((\3)=??*)$LOG(w    \3)|)"

Sidki feel free to delete/resume my above posts if you consider it


RE: sidki-config: Feb 13 2009 - Toppy - Mar. 13, 2009 09:56 PM

I have a little question, although there is :
Code:
web.archive.org/        $SET(0=a_rdlink.b_refer.)
... in the IncludeExclude.ptxt file, the normal link is converted to the so-called site, and the correct link pops up in "Tracking Link" pop-over.

Example site (search for : A comparison between some resizers is given )
http://avisynth.org/mediawiki/Spline64Resize


RE: sidki-config: Feb 13 2009 - sidki3003 - Mar. 13, 2009 11:51 PM

The URL match of IncludeExclude entries refers to the current page, not to the links in the current page.
So the entry you quoted only matches for page (i.e, location, versus <a href=...> ) URLs that start with "web.archive.org/".


RE: sidki-config: Feb 13 2009 - lnminente - Apr. 04, 2009 02:33 PM

Hi Sidki, this is the season of the cookies and i was taking a look to your filter "Set-Cookie: # Filter Cookie Content" and i realized the list CookieValues is only used for that filter. Could be interesting to write another filter wich would modify the outgoing cookies replacing the fake cookie and block cookie filters. In that way we could modify/empty/fake in a more general way using only one list some javascript cookies like the ones created by google reader when doing login.

The list i'm using contains the name of the Cookie, a test for uDom if needed, and the variable \0 with the new value to asign to that cookie field. Just an idea, i have been using a filter for Set-Cookie for some days and will try to write something for Cookie in the next hours...

To split the cookie in its fields i'm using
Code:
[HTTP headers]
In = FALSE
Out = FALSE
Key = "z<example> Cookies parsing {ln}090323b"
URL = "(^?)"
Match = "(([^;]+)\0(; |)\2 $LOG(C\0)($TST(\0=$LST(modCookies)(; |))|)$SET(tCookie=$GET(tCookie)\0\2))+"
Replace = "$GET(tCookie)"



RE: sidki-config: Feb 13 2009 - whenever - Apr. 04, 2009 02:59 PM

(Apr. 04, 2009 02:33 PM)lnminente Wrote:  Could be interesting to write another filter wich would modify the outgoing cookies replacing the fake cookie and block cookie filters.
They are already in sidki's set.

Take a look at Cookie: 1 Block Cookies and Cookie: 2 Fake Cookies on sel. Sites filters and related sections in IncludeExclude-U.ptxt file.


RE: sidki-config: Feb 13 2009 - lnminente - Apr. 04, 2009 03:21 PM

Thanks Whenever, I went to IncludeExclude-U.ptxt and i saw three areas for doing exceptions.
The filter Block Cookies, i think it is for blocking the full outgoing cookie. And if i'm right the filter Fake Cookies on sel. sites, is replacing also the full cookie, all his fields.

What i say here is to focus on the fields of all the cookies using only one list. The concept is the same than blocking functions from javascript files, instead of the full javascript file.

So we could focus in typical tracking cookie fields like __utma, __utmb, __utmc etc... Also we could set our preferences for google in this list, to autologin in this forum, etc...


RE: sidki-config: Feb 13 2009 - sidki3003 - Apr. 04, 2009 03:52 PM

(Apr. 04, 2009 03:21 PM)lnminente Wrote:  The filter Block Cookies, i think it is for blocking the full outgoing cookie. And if i'm right the filter Fake Cookies on sel. sites, is replacing also the full cookie, all his fields.

Yes, it replaces the entire set-cookie string, unless you use one of the two modifiers, which are explained in the respective list comment.


Quote:So we could focus in typical tracking cookie fields like __utma, __utmb, __utmc etc...

This type of JS tracking cookies should definitely be blocked on function/script level, *before* it comes into existence.



If i get you right you are discussing two different things:

1 - Add another filter targeting the "Cookie" header, using the same CookieValues list.

Yes, it has a useful aspect when it comes to modifying JavaScript generated cookies. And only there. I had it like that for a while (i.e., a Cookie header filter using the same list), because there was a site (linux.com) which stored a redirect URL in a JS cookie. Turned out it was the only site doing that, and it stopped doing that after a few months.

Personally, i didn't find it comfortable to handle two different versions of a respective cookie: The one the browser had stored (and was still using for document.cookie tests, of course). And the one that got sent back via HTTP.

Right now, if a specific JS generated cookie is causing trouble, i simply override it via the IncludeExclude list.


2 - Do all the cookie faking from that same CookieValues list.

I agree that this list gives more fine control over what part of the cookie we like to modify exactly. However, usually that isn't necessary. Luckily, because it allows us to just test the cookies coming from a specific URL, and not every phreaking cookie in the world. Smile!

There's one important exception. The Google PREF cookie does require a lot of fine control. Which is why it is included in that list.


RE: sidki-config: Feb 13 2009 - lnminente - Apr. 04, 2009 04:49 PM

You got me right, the idea is to get these actual two things plus some blocking/emptying joined in only one list for modifying cookies.

(Apr. 04, 2009 03:52 PM)sidki3003 Wrote:  1... Yes, it has a useful aspect when it comes to modifying JavaScript generated cookies...
Yes, speaking about tracking cookies, it's nice to have it blocked with javascritpt, but the functions could change its name anytime more frequently than the name of the cookie, so doing this it would be more stable. No need to say it could be maintained for most of us, but disabling/modifying the specifical javascript function wich writes these cookies is something wich can't be done by anyone.

(Apr. 04, 2009 03:52 PM)sidki3003 Wrote:  Personally, i didn't find it comfortable to handle two different versions of a respective cookie: The one the browser had stored (and was still using for document.cookie tests, of course). And the one that got sent back via HTTP.
Yes, it can be complex, but that's what we do when faking a cookie. In the list can be included a test in the values to make it work only when incoming or outgoing or for both situations.

(Apr. 04, 2009 03:52 PM)sidki3003 Wrote:  I agree that this list gives more fine control over what part of the cookie we like to modify exactly. However, usually that isn't necessary. Luckily, because it allows us to just test the cookies coming from a specific URL, and not every phreaking cookie in the world
Well, cookies thing neither keeps me awake, neither tracking webbugs really, but what i like more is the level of control this "tool" would give us. I will play a bit with it and will post the filters if i don't get struggled [Image: happy0034.gif]


RE: sidki-config: Feb 13 2009 - JD5000 - Apr. 27, 2009 11:27 AM

Great to see you're keeping your config going old friend. Eyes Closed Smile