The Un-Official Proxomitron Forum

Full Version: Proxomitron Reborn
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
As for enhancements...something simple and nonfunctional just for comments, like $NOTE() or $REM() or $FOO() or some such, would be kind'a nice.
(Jun. 20, 2018 03:45 AM)amy Wrote: [ -> ]try to think of some enhancements you'd like.

Generate certs to 'hide' the Proxomitron from the client.
Add https to local.ptron
Finish SSL Certificate Validation Dialog (171). IIRC, 'Allow for Session' didn't.
Block or log unknown headers.
Provide for Brotli and HPACK.

That's enough for now.
There was more. Wink

Don't let Proxo steal too much time.
Have fun.
Nice work :-)

* Make the GUI DPI aware (on 4K it looks small)
* Make it remember the widths of the webpage, header and editor windows between restarts of the program. Its so "narrow" at first.
(Jun. 22, 2018 05:01 PM)prxymouse Wrote: [ -> ]* Make it remember the widths of the webpage, header and editor windows between restarts of the program. Its so "narrow" at first.

After you adjust them, use 'Save Config File' under 'File' on the Proxomitron's main dialog. This should save the changes to the [WinSizes] section of the active cfg file.

Clicking the green floppy should also save the changes but it isn't always available.
(Jun. 22, 2018 09:02 PM)JJoe Wrote: [ -> ]After you adjust them, use 'Save Config File' under 'File' on the Proxomitron's main dialog. This should save the changes to the [WinSizes] section of the active cfg file.
You learn something new every day :-)
Getting SSL to work in Proxomitron is a bit finicky (in my opinion) and I like the way Proxydomo has integrated it into the GUI and code, you can simply click a button and restart:

Step 1, click generate, you have two options:[attachment=1049]
Step 2, and you're done [attachment=1050]

See https://github.com/amate/Proxydomo (uses wolfssl - https://www.wolfssl.com/)
Let it be known that I am well aware of the difficulties around getting SSL/TLS filtering to work, having developed the patches to use newer OpenSSL, and that improvements to it is one of the top priorities amongst all the upcoming new features.

Good things come to those who wait. Keep on testing .7 for now Thumbs Up
i'd personally prefer a checkbox option in the settings to DISABLE any and ALL cert checks...

i personally feel much MUCH more "secure" NOT having them !!!...
(Jun. 29, 2018 03:42 PM)ProxRocks Wrote: [ -> ]i'd personally prefer a checkbox option in the settings to DISABLE any and ALL cert checks...

i personally feel much MUCH more "secure" NOT having them !!!...
The current version already lets you do that --- just delete/rename the certs.pem .
As I am going through the list of existing bugs in the original 4.5j and fixing them, I came across this one:
Quote:Header filter order in config file changes upon save
and this one is related:
Quote:Header filter list box does not reflect order in which header filters are applied
I think we all agree that the order should not change just by loading and saving the same config file that already has them in some consistent order, but what do you think the correct order should be? Currently, it seems that when it loads, it tries to keep URL: filters at the beginning of its internal list, but the code for that is a little buggy (hence the URL: filters sometimes don't show up at the beginning, and sometimes they do.) I believe Scott intended for URL: filters to be applied before all others, hence the code to treat them differently.

Also, having decided on an order in the config file, what order should be shown in the header filters dialog? The same order as in its internal list (and thus the order in which they are applied), or the current "sorted" order?

Would it break any existing filters? Are there both users who rely on URL: filters at the top, and those who rely on them being sorted "alphabetically"?

If we can make a decision on this, 4.5.2.0 will contain this fix (among many others.)
(Jul. 23, 2018 11:40 AM)amy Wrote: [ -> ]but the code for that is a little buggy

This is the reason the sidki set does not use URL: style filters. Some of the set's filters must act before others.

ReadMe.txt Wrote:*******************************************************************************
Importing URL Header Filters
*******************************************************************************

Don't import "URL:" style header filters into this config without editing!
They have a special status which lets the header filters sort order swap
between two states, making the order in which the filters match unpredictable.

Converting a "URL:" filter to one that doesn't interfere is easy:

Old:
[HTTP headers]
In = FALSE
Out = TRUE
Key = "URL: Kill somesite.com (Out)"
Match = "http://somesite.com/"
Replace = "\k"

New:
[HTTP headers]
In = FALSE
Out = TRUE
Key = "!-|||||||||||| URL: Kill somesite.com (Out)"
URL = "somesite.com/"
Replace = "\k"

If you need to match the protocol, there is a global variable "uProt" for that:
URL = "somesite.com/&$TST(uProt=http:)"

My vote is for the header filter list to reflect the order that the filters are actually applied, whatever the order may be.

Possible orders:
1. Alphabetized but URL type goes first.
2. Alphabetized but URL type ignored.
3. Alphabetized.
4. User specified.

1 maintains continuity.
1 or 3 would be best for the novice.
4 should be easiest to code.


There is another bug that causes problems for users of sets that require a specific header filter order.

sidki Wrote:If you like to try this filter, then - besides merging it - you'd also *have* to do a "Configure -> OK -> Save" from Proxomitron's main window several times, in order to get it into the right "physical" position.
config -> access -> allow access to the following IP address range
From:192.168.0.0 To:192.168.0.255
save
goto access again
the accessrange autochange to:
From:192.168.0.255 To:192.168.0.0
(Jul. 23, 2018 06:58 PM)JJoe Wrote: [ -> ]My vote is for the header filter list to reflect the order that the filters are actually applied, whatever the order may be.

Possible orders:
1. Alphabetized but URL type goes first.
2. Alphabetized but URL type ignored.
3. Alphabetized.
4. User specified.

1 maintains continuity.
1 or 3 would be best for the novice.
4 should be easiest to code.

Anything except #2.
After giving it some more thought, I also believe that having the header filter dialog order be the same order they're applied makes the most sense, so consider that decided unless someone here can come up with a very good reason to use a different order.

I'm currently leaning in the direction of having URL: filters always come first (sorted alphabetically as a group) in the internal list and also at the top of the config file order (i.e. saving a config file will always produce this order), but am open to more suggestions on this. I'll leave this one alone for a while in case anyone else has some opinion it.
(Jul. 24, 2018 04:06 AM)referrer Wrote: [ -> ]config -> access -> allow access to the following IP address range
From:192.168.0.0 To:192.168.0.255
save
goto access again
the accessrange autochange to:
From:192.168.0.255 To:192.168.0.0
Thanks, will be fixed in 4.5.2.0.
Suggestion regarding the test window: If possible give the edit controls some basic shortcut functions:
- ctrl+a = select all
- ctrl-f = find (probably not easy)
- perhaps others...
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Reference URL's