Download blocker problem
 

News:

29 December 2022 - PtokaX 0.5.3.0 (20th anniversary edition) released...
11 April 2017 - PtokaX 0.5.2.2 released...
8 April 2015 Anti child and anti pedo pr0n scripts are not allowed anymore on this board!
28 September 2015 - PtokaX 0.5.2.1 for Windows 10 IoT released...
3 September 2015 - PtokaX 0.5.2.1 released...
16 August 2015 - PtokaX 0.5.2.0 released...
1 August 2015 - Crowdfunding for ADC protocol support in PtokaX ended. Clearly nobody want ADC support...
30 June 2015 - PtokaX 0.5.1.0 released...
30 April 2015 Crowdfunding for ADC protocol support in PtokaX
26 April 2015 New support hub!
20 February 2015 - PtokaX 0.5.0.3 released...
13 April 2014 - PtokaX 0.5.0.2 released...
23 March 2014 - PtokaX testing version 0.5.0.1 build 454 is available.
04 March 2014 - PtokaX.org sites were temporary down because of DDOS attacks and issues with hosting service provider.

Main Menu

Download blocker problem

Started by Naithif, 19 December, 2006, 13:38:13

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Naithif

Hi all

I've a problem with the simple download blocker part of my script

tCantDownload = 	{ [0] = 0, [1] = 0, [2] = 0, [3] = 0, [-1] = 1 }
bCantDownloadInPm = true

function ConnectToMeArrival(User, Data)
	if tCantDownload[User.iProfile] == 1 then
		if bCantDownloadInPm == true then
			User:SendPM(HubBot, sCantDownload)
		else
			User:SendData(HubBot, sCantDownload)
		end
	return 1
	end
end


RevConnectToMeArrival = ConnectToMeArrival
SearchArrival = ConnectToMeArrival



The problem is that no passive registered users (profiles 0, 1, 2, 3) can download from an active user (profile -1)
I can't seem to understand this, searched for other scripts, but as I saw all in common with the way RevConnectToMeArrivals are handled.
Can somebody help me with this? Thanks in advance

Thor

#1
sCantDownload isn't declared, got nil, and script don't disard the data.
+
http://forum.ptokax.org/index.php?topic=6473#msg63640

Naithif

That string's declared in my script, I'm not soooo (Maybe.) stupid, just forgot to paste it here. (I've pasted the first two lines after the rest, and didn't noticed the message string)

Well, thanks for the link. - It's funny 'cause it wasn't long ago.
The only thing left to do then is to wish that maybe PPK implants it into PtokaX. ([beady little eyes] please? ::))

(Where's my head these days)

bastya_elvtars

Naithif, your problem originates from the protocol specification. On a $RevConnectToMe the target client sends a $ConnectToMe to the source client because the peer-to-peer connection can only be established this way (one of the clients is passive). Therefore, you have to enter allowed passive users to a table on $RCTM and remove if the same user does the $CTM afterwards.
Everything could have been anything else and it would have just as much meaning.

Naithif

#4
Yip I've been thinking some about this in the past few days

It's because the passive user (non -1 profile) sends RevConnectToMe and the other replies with a ConnectToMe, with blocked profile (-1, user) that's easy to understand an it's clear

The sender of RevConnectToMe is always that client that's the downloader - good as blocked if profile matches
The sender of ConnectToMe can be either the downloader or the victim - It should be split into two cases?

--> Check ConnectToMe connections, if there was a RevConnectToMe before it?

If there was, don't block it (this case RevConnectToMe would have already been blocked if the profile would match, so if RevConnectToMe sent it, and got through, it's good (passive non user))
If there wasn't, block it after a profile check (active sender, if fails on profile check, should be blocked)

This would require a monitoring of connections
Like RevConnectToMe users (if they are through the profile check) would send any confirmation info (like a value set) with the other users name (it can be read through a string.find, right?) and upon ConnectToMeArrival only connections confirmed with this info should be allowed?

Dammit, it isn't as easy as it looks :D
My question: Can this be made, or is there some other errors in it? (I just need the answer)

Edit: [Offtopic] Nice petition Bastya, I like it, is there a topic about it, or something at this board? Maybe voting or stuff  :D

bastya_elvtars

Well, you can do with a table with $RCTM username as key and target username as value. It needs a trick because of CTM, but I am sure you'll find the solution. ;-)

Edit: I don't know if you can do it with a coroutine, but maybe it's worth trying (yield until no match perhaps ).
Everything could have been anything else and it would have just as much meaning.

Naithif

#6
Not really these days I'm afraid, I've got loads of stuff to do (and more in january...).
Big thanks for the advice Bastya, I'll look into it sometime, maybe a crude version will come up soon or something

Edit:
Quote from: bastya_elvtars on 19 December, 2006, 21:21:14
Well, you can do with a table with $RCTM username as key and target username as value.

Do we need that target username into the table?
I mean RCTM sets the 'Confirmed' value to the User.sName ('User' is the triggerer) in the table (if passed of course)
And CTM checks for the 'Confirmed' value with the Connecter.sName ('Connecter' is the one who connects to the triggerer in this case) in the table
(it seems that the connecter to the triggerer ('Connecter') can be grabbed with string.find, just seen it with Mutor's script :) )

Naithif

#7
I dunno if it's right, but tested it with Passive and Active normal users, and regged Passives

Results for me: normal user blocked, passive regged NOT blocked  :D

Please test it who can, I'm not sure in it (I've tested it some, but I don't know)

HubBot = frmHub:GetHubBotName()
bSwitchOnCantDownload = true
tCantDownload = 	{ [0] = 0, [1] = 0, [2] = 0, [3] = 0, [-1] = 1 }
bCantDownloadInPm = true
sCantDownload = "\r\n\r\nRegisztr?ci? n?lk?l nem t?lthetsz ?s kereshetsz ezen a hubon. Ha regisztr?lni szeretn?l, keress meg egy oper?tort ?s V?RJ T?RELMESEN.\r\nOhne Registrieren kannst du nicht in diesem Hub downloaden und suchen. Wenn du registriert sein willst, frag einen Operator und WARTE GEDULDIG.\r\nWithout registration, you are not allowed to download and search in this hub. If you want to register, ask an operator and WAIT PATIENTLY.\r\n"
tConfirmed = { }



function RevConnectToMeArrival(User, Data)
	if bSwitchOnCantDownload == true then
		if tCantDownload[User.iProfile] == 1 then
			if bCantDownloadInPm == true then
				User:SendPM(HubBot, sCantDownload)
			else
				User:SendData(HubBot, sCantDownload)
			end
		return 1
		else
		tConfirmed[User.sName] = "A"
		end
	end
end


function ConnectToMeArrival(User, Data)
	if bSwitchOnCantDownload == true then
		if tCantDownload[User.iProfile] == 1 then

    			local s,e,CTM = string.find(Data,"$ConnectToMe%s+(%S+)")
  		  	local s,e,RCTM = string.find(Data,"^$RevConnectToMe%s+%S+%s+(%S+)|$")

		    	if CTM ~= nil then Connecter = GetItemByName(CTM); end
		    	if RCTM ~= nil then Connecter = GetItemByName(RCTM); end



			if tConfirmed[Connecter.sName] ~= "A" then
				if bCantDownloadInPm == true then
					User:SendPM(HubBot, sCantDownload)
				else
					User:SendData(HubBot, sCantDownload)
				end
				return 1
			else
				tConfirmed[Connecter.sName] = ""
			end
		end
	end
end



function SearchArrival(User, Data) 
	if bSwitchOnCantDownload == true then
		if tCantDownload[User.iProfile] == 1 then
			if bCantDownloadInPm == true then
				User:SendPM(HubBot, sCantDownload)
			else
				User:SendData(HubBot, sCantDownload)
			end
		return 1
		end
	end
end


(sorry for the big deal of crap in this (like bSwitchOnCantDownload = true , and using a table for profiles who can't download), it can be made more simple of course with just the profile (-1) inserted, it was neater for me in the main script (and toggling should be in it). I've just ripped it off quickly)

Credits goes to Mutor, bastya_elvtars, and everyone else who identifies his/her code in this

Naithif

Nobody's testing or commenting ? :( If this one works / not works for anyone, or simply found something which isn't right, please give feedback... Sorry for double posting

Naithif

#9
Quote from: Mutor on 23 December, 2006, 18:47:57
I haven't tested the code, but I'm doubtful this would work.

local s,e,RCTM = string.find(Data,"^$RevConnectToMe%s+%S+%s+(%S+)|$")


should always be nil in:

function ConnectToMeArrival


It should only be available in:

function RevConnectToMeArrival


Yip, that's right

Quote from: Mutor on 23 December, 2006, 18:47:57
As was stated earlier, it would be best to build a atble from RCTM

Isn't the table is built by RCTM users in this script ???

function RevConnectToMeArrival(User, Data)
...
		tConfirmed[User.sName] = "A"
...


Quote from: Mutor on 23 December, 2006, 18:47:57
and then if the RCTM user matches the CTM remote nick, allow xfer.

function ConnectToMeArrival(User, Data)
...
				if tConfirmed[Connecter.sName] ~= "A" then
...


CTM remote is "Connecter"

Edit:
I've tested this script now, and it seems to work  ??? All reged could download, and unreged cannot BUT expect that:

It can't avoid the "established connection" problem, so if you're regged and start downloading from someone, they can start downloading from you too, which makes the whole script rather useless... (This problem is present in all of these scripts isn't it?) Seems like it's a lost case sorry for disturbing you with it

Naithif

Quote from: Mutor on 23 December, 2006, 20:14:16
you not accounting for multiple RCTM's
from the same passive user. I was suggesting your RCTM table entries  should
have a value of the remote nick, not just "A".

I thought clearing it upon each successful connection should be able to handle it :(

else
				tConfirmed[Connecter.sName] = ""


The main problem is the "established connection" problem I think :(
(After hiding share with clients, scripts and such, I can say that I don't agree with the "don't share / hide share" thing, just I hate leechers who enter the hub with minimal (and crappy) share and pulls down everything from all users - if you and other ops don't hide share it's easier to filter leechers)
(most leechers leave immediately if they can't download, and it's easier to get them back on 'wait' list by removing their reg if they act as a leecher eventually)

Naithif

Quote from: Mutor on 23 December, 2006, 21:02:42
It should, unless perhaps the connection speeds of the respective users plays a role.
So I'm thinking it's best to use numerical indices [arrays] and looping the table [with ipairs]
rather than hashing [tables] for what might be a common alpha-num. indice This would also
allow for the use of table.insert and table.remove

Sounds reasonable but this script will eventually leak, I think the way of sorting the table and adding the connecter with indexes would fix 1:100th of the leaking errors.
I mean no disrespect, it should be better your way, but if there's a great hole in the ship I can't see the reason to fix the small one.
With unregs can download when a reg downloads from them (or even can start) this script has a great hole in it.

Naithif

Quote from: Mutor on 24 December, 2006, 01:44:28
In any rate the protocol limitations on 'blocking' transfers will exist
until such protocol is changed, thus the advent of ADC. I dont wish
to start a debate on ADC but if nothing else it was an attempt at change.

I don't seem to understand because I've leafed through ADC documentation (0.12) but not even connect methods have changed in the ADC protocol (CTM arrival) :( (at least yet, and how it's documented)
I haven't found anything descriptive regarding how the actual connections going on - I mean what happens on different side transfers if the connection is established.

bastya_elvtars

Erm well, I download from you but you aren't allowed to download from me.
How would this look in the rules? :)
Everything could have been anything else and it would have just as much meaning.

Naithif

Yes, you're somewhat right, maybe this script's beauty is in it's imperfection
Anyway, I only added it into my script in case it would be needed (not like I think it so :D) and came across that problem, and tried to solve it, it succeded in some crude way as I guessed it earlier.
I'm not planning to use it

(And B?stya, I've seen enough "you must be regged to be able to download here" messages to know that it looks shit in the rules  ;D It's the same as not letting people enter the hub without reg)

TTB

Hi,

I've just created such script, and indeed... this is also a problem I faced with. Putting a nick in a temp table by RevCon, to establish a connection in CTM works, but the other user can still download when the connection has been made. Just confirming the problem. Afaik, there is no way to solve this problem. Blocked users can always download from "allowed" users who set up the connection.
TTB

(? ?.??.-> Admin @ Surfnet hubs <-.??.???)

TTB

Quote from: Mutor on 14 November, 2007, 02:34:00
I really don't think so because this must happen after the
transfers has been initiated and is then client to client [after
the hub has handed the request off].
I mean... when a non-allowed user try's to download from an allowed user, the connection is blocked. The filelist remains in the downloadqueue. When the connection is established (by the allowed user), the non-allowed will get the filelist. As long as the connection remains, the non-allowed will be able to download from the allowed user.

Am I wrong Mutor?
TTB

(? ?.??.-> Admin @ Surfnet hubs <-.??.???)

Naithif

#17
Quote from: TTB on 14 November, 2007, 11:57:00
I mean... when a non-allowed user try's to download from an allowed user, the connection is blocked. The filelist remains in the downloadqueue. When the connection is established (by the allowed user), the non-allowed will get the filelist. As long as the connection remains, the non-allowed will be able to download from the allowed user.

Am I wrong Mutor?

True (As it was written above, and was discussed throughout)

Other implementations has only more flaws thou - for example, another hubsoft has block download at hub level, but reconnecting to the hub makes the connection up'n'go.

Every (including my old script above) version of download blocker is VERY flawed, and isn't possible to fix, because it was never meant to be this way.

Besides, that script & discussion was at that time when there wasn't any blocker scripts (at least not public), just those ones that blocked all passives. Since then there are way betters, with discussion in most topics where they are.

TTB

There is a way, but allowed users won't also be able to download from non-allowed users. Only this way the block works.

TTB

(? ?.??.-> Admin @ Surfnet hubs <-.??.???)

SMF spam blocked by CleanTalk