Advanced search  

News:

CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Pages: [1] 2   Go Down

Author Topic: Limit Viewing  (Read 21819 times)

0 Members and 1 Guest are viewing this topic.

Raisingdad

  • Coppermine newbie
  • Offline Offline
  • Posts: 13
Limit Viewing
« on: January 15, 2005, 09:55:13 pm »

My Feature Request:

Allowing admin to limit User Groups Viewing of Pictures (or anybody), by setting a Time Frame Flood Limit.

IE. View 30 pictures in 1 Hour, to stop Bots, and to stop Abusive Users from running up Bandwdith.
Logged

andy_cul

  • Coppermine regular visitor
  • **
  • Offline Offline
  • Gender: Male
  • Posts: 63
  • Incigida
Re: Limit Viewing
« Reply #1 on: May 10, 2005, 05:26:27 pm »

Is this possible? Because this is what my website needs.
Logged

autobahn

  • Coppermine newbie
  • Offline Offline
  • Posts: 2
Re: Limit Viewing
« Reply #2 on: May 10, 2005, 10:26:41 pm »

the problem is your users could always just directly hotlink to the pictures on the server. you can disable that but it disables it for everyone.
Logged

Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47843
  • aka "GauGau"
    • gaugau.de
Re: Limit Viewing
« Reply #3 on: May 11, 2005, 10:01:45 am »

what you're requesting is currently not possible, and I doubt that such a feature will be implemented in the core code of future coppermine versions. Of course everybody is welcome to post a hack instead.
Logged

Loki66

  • Coppermine novice
  • *
  • Offline Offline
  • Posts: 29
Re: Limit Viewing
« Reply #4 on: May 23, 2005, 12:32:37 pm »

I dont' agree, there are various ways to limit bandwith abuse (hotlinking, ....). Here is a summary taken from WinHTTrack :

Hope that somebody will implement this with Coppermine because this is a key feature for CPG to become "professional" ...


Bandwidth abuse:

Many Webmasters are concerned about bandwidth abuse, even if this problem is caused by a minority of people. Offline browsers tools, like HTTrack, can be used in a WRONG way, and therefore are sometimes considered as a potential danger.
But before thinking that all offline browsers are BAD, consider this: students, teachers, IT consultants, websurfers and many people who like your website, may want to copy parts of it, for their work, their studies, to teach or demonstrate to people during class school or shows. They might do that because they are connected through expensive modem connection, or because they would like to consult pages while travelling, or archive sites that may be removed one day, make some data mining, comiling information ("if only I could find this website I saw one day..").
There are many good reasons to mirror websites, and this helps many good people.
As a webmaster, you might be interested to use such tools, too: test broken links, move a website to another location, control which external links are put on your website for legal/content control, test the webserver response and performances, index it..

Anyway, bandwidth abuse can be a problem. If your site is regularly "clobbered" by evil downloaders, you have
various solutions. You have radical solutions, and intermediate solutions. I strongly recomment not to use
radical solutions, because of the previous remarks (good people often mirror websites).

In general, for all solutions,
the good thing: it will limit the bandwidth abuse
the bad thing: depending on the solution, it will be either a small constraint, or a fatal nuisance (you'll get 0 visitors)
or, to be extreme: if you unplug the wire, there will be no bandwidth abuse


Inform people, explain why ("please do not clobber the bandwidth")
Good: Will work with good people. Many good people just don't KNOW that they can slow down a network.
Bad: Will **only** work with good people
How to do: Obvious - place a note, a warning, an article, a draw, a poeme or whatever you want


Use "robots.txt" file
Good: Easy to setup
Bad: Easy to override
How to do: Create a robots.txt file on top dir, with proper parameters
Example:
    User-agent: *

    Disallow: /bigfolder


Ban registered offline-browsers User-agents
Good: Easy to setup
Bad: Radical, and easy to override
How to do: Filter the "User-agent" HTTP header field


Limit the bandwidth per IP (or by folders)
Good: Efficient
Bad: Multiple users behind proxies will be slow down, not really easy to setup
How to do: Depends on webserver. Might be done with low-level IP rules (QoS)


Priorize small files, against large files
Good: Efficient if large files are the cause of abuse
Bad: Not always efficient
How to do: Depends on the webserver


Ban abuser IPs
Good: Immediate solution
Bad: Annoying to do, useless for dynamic IPs, and not very user friendly
How to do: Either ban IP's on the firewall, or on the webserver (see ACLs)


Limit abusers IPs
Good: Intermediate and immediate solution
Bad: Annoying to do, useless for dynamic IPs, and annoying to maintain..
How to do: Use routine QoS (fair queuing), or webserver options


Use technical tricks (like javascript) to hide URLs
Good: Efficient
Bad: The most efficient tricks will also cause your website to he heavy, and not user-friendly (and therefore less attractive, even for surfing users). Remember: clients or visitors might want to consult offline your website. Advanced users will also be still able to note the URLs and catch them. Will not work on non-javascript browsers. It will not work if the user clicks 50 times and put downloads in background with a standard browser
How to do: Most offline browsers (I would say all, but let's say most) are unable to "understand" javascript/java properly. Reason: very tricky to handle!
Example:
You can replace:
    <a href="bigfile.zip">Foo</a>
by:
    <script language="javascript">
    <!--
    document.write('<a h' + 're' + 'f="');
    document.write('bigfile' + '.' + 'zip">');
    // -->
    </script>
    Foo
    </a>

You can also use java-based applets. I would say that it is the "best of the horrors". A big, fat, slow, bogus java applet. Avoid!


Use technical tricks to lag offline browsers
Good: Efficient
Bad: Can be avoided by advanced users, annoying to maintain, AND potentially worst that the illness (cgi's are often taking some CPU usage). . It will not work if the user clicks 50 times and put downloads in background with a standard browser
How to do: Create fake empty links that point to cgi's, with long delays
Example: Use things like <ahref="slow.cgi?p=12786549"><nothing></a> (example in php:)
    <?php
    for($i=0;$i<10;$i++) {
        sleep(6);
        echo " ";
    }
    ?>


Use technical tricks to temporarily ban IPs
Good: Efficient
Bad: Radical (your site will only be available online for all users), not easy to setup
How to to: Create fake links with "killing" targets
Example: Use things like <a href="killme.cgi"><nothing></a> (again an example in php:)

<?php
   // Add IP.
   add_temp_firewall_rule($REMOTE_ADDR,"30s");
?>
function add_temp_firewall_rule($addr) {
   // The chain chhttp is flushed in a cron job to avoid ipchains overflow
    system("/usr/bin/sudo -u root /sbin/ipchains -I 1 chhttp -p tcp -s ".$addr." --dport 80 -j REJECT");
    syslog("user rejected due to too many copy attemps : ".$addr);
}







Copyright issues

You do not want people to "steal" your website, or even copy parts of it. First, stealing a website does not
require to have an offline browser. Second, direct (and credited) copy is sometimes better than disguised
plagiarism. Besides, several previous remarks are also interesting here: the more protected your website will be,
the potentially less attractive it will also be. There is no perfect solution, too. A webmaster asked me one day
to give him a solution to prevent any website copy. Not only for offline browsers, but also against "save as",
cut and paste, print.. and print screen. I replied that is was not possible, especially for the print screen - and
that another potential threat was the evil photographer. Maybe with a "this document will self-destruct in 5 seconds.."
or by shooting users after consulting the document.
More seriously, once a document is being placed on a website, there will always be the risks of copy (or plagiarism)

To limit the risk, previous a- and h- solutions, in "bandwidth abuse" section, can be used



Privacy

Might be related to section 2.
But the greatest risk is maybe email grabbers.


A solution can be to use javascript to hide emails.
Good: Efficient
Bad: Non-javascript browsers will not have the "clickable" link
How to do: Use javascript to build mailto: links
Example:
    <script language="javascript">
    <!--
    function FOS(host,nom,info) {
      var s;
      if (info == "") info=nom+"@"+host;
      s="mail";
      document.write("<a href='"+s+"to:"+nom+"@"+host+"'>"+info+"</a>");
    }
    FOS('mycompany.com','smith?subject=Hi, John','Click here to email me!')
    // -->
    </script>
    <noscript>
    smith at mycompany dot com
    </noscript>


Another one is to create images of emails
Good: Efficient, does not require javascript
Bad: There is still the problem of the link (mailto:), images are bigger than text, and it can cause problems for blind people (a good solution is use an ALT attribute with the email written like "smith at mycompany dot com")
How to do: Not so obvious of you do not want to create images by yourself
Example: (php, Unix)
<?php
/*
Email contact displayer
Usage: email.php3?id=<4 bytes of user's md5>
The <4 bytes of user's md5> can be calculated using the 2nd script (see below)
Example: http://yourhost/email.php3?id=91ff1a48
*/
$domain="mycompany.com";
$size=12;

/* Find the user in the system database */
if (!$id)
  exit;
unset($email);
unset($name);
unset($pwd);
unset($apwd);
$email="";
$name="";
$fp=@fopen("/etc/passwd","r");
if ($fp) {
  $pwd=@fread($fp,filesize("/etc/passwd"));
  @fclose($fp);
}
$apwd=split("\n",$pwd);
foreach($apwd as $line) {
  $fld=split(":",$line);
  if (substr(md5($fld[0]),0,8) == $id) {
    $email=$fld[0]."@".$domain;
    $nm=substr($fld[4],0,strpos($fld[4],","));
    $name=$email;
    if ($nm)
      $name="\"".$nm."\" <".$email.">";
  }
}
if (!$name)
  exit;

/* Create and show the image */
Header ("Content-type: image/gif");
$im = imagecreate ($size*strlen($name), $size*1.5);
$black = ImageColorAllocate ($im, 255, 255, 255);
$white = ImageColorAllocate ($im, 0,0,0);
ImageTTFText($im, $size, 0, 0, $size , $white, "/usr/share/enlightenment/E-docs/aircut3.ttf",$name);
ImageGif ($im);
ImageDestroy ($im);
?>

The script to find the id:

#!/bin/sh

# small script for email.php3
echo "Enter login:"
read login
echo "The URL is:"
printf "http://yourhost/email.php3?id="
printf $login|md5sum|cut -c1-8
echo


You can also create temporary email aliases, each week, for all users
Good: Efficient, and you can give your real email in your reply-to address
Bad: Temporary emails
How to do: Not so hard todo
Example: (script & php, Unix)
#!/bin/sh
#
# Anonymous random aliases for all users
# changed each week, to avoid spam problems
# on websites
# (to put into /etc/cron.weekly/)

# Each alias is regenerated each week, and valid for 2 weeks

# prefix for all users
# must not be the prefix of another alias!
USER_PREFIX="user-"

# valid for 2 weeks
ALIAS_VALID=2

# random string
SECRET="my secret string `hostname -f`"

# build
grep -vE "^$USER_PREFIX" /etc/aliases > /etc/aliases.new
for i in `cut -f1 -d':' /etc/passwd`; do
  if test `id -u $i` -ge 500; then
    off=0
    while test "$off" -lt $ALIAS_VALID; do
      THISWEEK="`date +'%Y'` $[`date +'%U'`-$off]"
      SECRET="`echo \"$SECRET $i $THISWEEK\" | md5sum | cut -c1-4`"
      FIRST=`echo $i | cut -c1-3`
      NAME="$USER_PREFIX$FIRST$SECRET"
      echo "$NAME : $i" >> /etc/aliases.new
      #
      off=$[$off+1]
    done
  fi
done

# move file
mv -f /etc/aliases /etc/aliases.old
mv -f /etc/aliases.new /etc/aliases

# update aliases
newaliases

And then, put the email address in your pages through:

<a href="mailto:<?php
    $user="smith";
    $alias=exec("grep ".$user." /etc/aliases | cut -f1 -d' ' | head -n1");
    print $alias;
?>@mycompany.com>>
Logged

Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47843
  • aka "GauGau"
    • gaugau.de
Re: Limit Viewing
« Reply #5 on: May 24, 2005, 06:54:35 am »

I agree that it's impossible to make any website bullet-proof against copy cats, but most often it helps to make it harder for newbies to steal. Most newbie website owners fall for easy tricks and try to implement silly "no-right-click" JavaScript gimmicks, which are very annoying in the first place.

This is my recommendation for those who actually want to protect their site against bandwidth theft:
  • set up hotlink protection using htaccess methods:
    I set up a .htaccess file that resides in the albums folder of my personal homepage that looks like this:
Code: [Select]
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mysite.tld(/)?.*$     [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?site-of-a-friend-who-is-allowed-to-hotlink.tld(/)?.*$     [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?another-site-of-a-friend.tld(/)?.*$     [NC]
RewriteRule .*\.(gif|jpg|jpeg|bmp)$ http://mysite.tld/pic/that/is/displayed/when/somebody/hotlinks/stolen.gif [R,NC]
  • Put the actual pic as background image of a table, and a transparent one-pixel gif as content of the table cell:
    This has to be implemented into future versions of coppermine (as admin option of course). If a user does a right-click, save image as, all he will steal is a useless empty gif.
    Disadvantage: will only fool newbie users

As I said above: all other methods of reducing bandwidth usage, e.g. by counting the number of pics a registered user has made and not letting him view more than X pics within a certain period is difficult to implement and will require additional queries to be run. You database will become fatter, and coppermine will load slower. I'm not convinced that such a feature should be implemented into coppermine's core code, although it would drastically limit abuse by leechers, but as well spidering by search engines.
« Last Edit: February 19, 2006, 11:36:42 am by GauGau »
Logged

Loki66

  • Coppermine novice
  • *
  • Offline Offline
  • Posts: 29
Re: Limit Viewing
« Reply #6 on: May 24, 2005, 09:27:46 am »

Is it possible to make the following changes with CPG ?

 
http://www.mysite.com/albums/album 1/thum_xyz0001.jpg
 
http://www.mysite.com/albums/album 1//normal_xyz0001.jpg
 
http://www.mysite.com/albums/album 1/originalname.jpg

all thumbnails and intermediate pics are renamed by the script so that the original name of the pic is preserved .............

Thanks,

Loki
Logged

Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47843
  • aka "GauGau"
    • gaugau.de
Re: Limit Viewing
« Reply #7 on: May 24, 2005, 10:25:10 am »

being considered, but any naming scheme that we will come up with is bound to break, as there surely will be users who just name their files in a way that collides with anything you can possible come up with. We believe in doing as few file-level operations as possible: with so many people around who don't have the slightest idea what CHMOD is (search the support board to get a rough idea how many people fail to do this simple operation), there surely will be some where there (silly) server setup will prevent coppermine from doing what it currently can do just fine. Another naming scheme means additional checks needed (if a file exists etc.), which will be even harder with filesnames in non-latin encoding.
In other words: we're very reluctant to change anything there.

Joachim
Logged

Loki66

  • Coppermine novice
  • *
  • Offline Offline
  • Posts: 29
Re: Limit Viewing
« Reply #8 on: May 25, 2005, 05:55:49 pm »

Original picture names can be generated from the original name by some simple function like:
get first 3 digits of the name and encipher them with md5 algorithm.
This way it won't confuse with any other names.

For sure, its is a technical challenge but do we want Coppermine to become the best ASP gallery software or not ?. Newbies have to learn to swim ...as there are sharks in the water.

Loki
Logged

Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47843
  • aka "GauGau"
    • gaugau.de
Re: Limit Viewing
« Reply #9 on: May 26, 2005, 08:18:12 am »

asp? ::) I prefer PHP... ;)
Logged

Loki66

  • Coppermine novice
  • *
  • Offline Offline
  • Posts: 29
Re: Limit Viewing
« Reply #10 on: May 30, 2005, 12:20:57 am »

Heuu, sorry, I meant "online" .... ;)
Logged

Loki66

  • Coppermine novice
  • *
  • Offline Offline
  • Posts: 29
Re: Limit Viewing
« Reply #11 on: May 31, 2005, 08:30:18 pm »

So can we have this function, protection of original pics, agreed so it become a full feature of CPG ?.

Loki
Logged

andy_cul

  • Coppermine regular visitor
  • **
  • Offline Offline
  • Gender: Male
  • Posts: 63
  • Incigida
Re: Limit Viewing
« Reply #12 on: July 02, 2005, 10:23:36 am »

but is the mod possible? this would be a great mod if ever coded
Logged

Loki66

  • Coppermine novice
  • *
  • Offline Offline
  • Posts: 29
Re: Limit Viewing
« Reply #13 on: July 04, 2005, 01:02:17 pm »

No reply .... Please put this feature in the wish list !
Logged

andy_cul

  • Coppermine regular visitor
  • **
  • Offline Offline
  • Gender: Male
  • Posts: 63
  • Incigida
Re: Limit Viewing
« Reply #14 on: July 04, 2005, 03:03:10 pm »

Quote
Please put this feature in the wish list !

I Secong Emotion  ;D

This will help me save a lot of bandwidth.
Logged

Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47843
  • aka "GauGau"
    • gaugau.de
Re: Limit Viewing
« Reply #15 on: July 05, 2005, 07:52:07 am »

@andy_cul: I think everybody has understood that you want this feature, no need to repeat this over.
If you need it that badly, why don't you code it, or hire someone to code it for you?
Logged

andy_cul

  • Coppermine regular visitor
  • **
  • Offline Offline
  • Gender: Male
  • Posts: 63
  • Incigida
Re: Limit Viewing
« Reply #16 on: July 05, 2005, 11:12:25 am »

sorry for being pesky  :-X

Quote
If you need it that badly, why don't you code it, or hire someone to code it for you?

Its ok i'll just wait someone to code it.  I'm not a programmer  ;D
Logged

Loki66

  • Coppermine novice
  • *
  • Offline Offline
  • Posts: 29
Re: Limit Viewing
« Reply #17 on: July 16, 2005, 01:07:11 am »

I would be more than happy fo find a coder that would implement that picture, is Mr Cul interested in joining me ?
Logged

lilleman

  • Coppermine newbie
  • Offline Offline
  • Posts: 14
Re: Limit Viewing
« Reply #18 on: July 18, 2005, 11:13:23 pm »

if someone can make a x gig limit per usergroup per day i would gladly donate some $ to that guy
like: group 1 (donators/members) = limit of 3 gigs/day
group 2 (non donators/non members)= limit of 1 gig/day
group 3 (admin/moderator)= unlimited
Logged

RatKing

  • Contributor
  • Coppermine regular visitor
  • ***
  • Offline Offline
  • Gender: Male
  • Posts: 85
    • Personal website
Re: Limit Viewing
« Reply #19 on: July 22, 2005, 03:53:21 pm »

I would love to take up hat chalange I'll see what I can do next week. This weekend I'm to bussy but during work I should be able to find a few hours to code this.

I'll see about making this in two flavors even as I can see the first requests comming in for that already:
  • Version one as suggested above per user group
  • Version two as will no doubt be requested per album

Both should be completely configurable without breaking the current CPG database, and of course should work on all platforms.

The price well thats not importand lets first see if it can be done, if so it will be published and a paypal donate button will be added somewhere so people can if they feel like paying for this send me some of their hard earned cash.  ;D
Logged
Pages: [1] 2   Go Up
 

Page created in 0.031 seconds with 20 queries.