473,403 Members | 2,071 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,403 software developers and data experts.

Limiting access to a website

I'm considering setting a website up for a club. I do not plan the contents
to be for public consumption, but on the other hand I'm not going to have
anything on there that is confidential, that would cause a problem if it
went further.

The basic reason is for publicity of club events. I want to make it easy to
use. I suspect a login with a password would be too much effort for most
people. I also note that computer literacy is not a skill all of them
have, the sort of people who have not got the computer skills to be
confident to shop on Amazon.

Basically the problem is communication. Some of them read quarterly
newsletters, some of them bin them. I send the occasional email out with a
list of events, but if I do it too often some of them will start ignoring
them. I have found telephoning people individually to be very successful,
but I am not paid to do it and have a life.

However, I need to be proactive rather than take the curl up and die
approach. For those who are keen on the idea a website might help.

I suspect that security through obscurity is just to lax, a url

http://foo.bar/tbntrjvoprnio/index.html

is just pointless.

My plan is as follows:

1. Make them log in using their email address as a username. Email them
their passwords first.

2. For people who have cookies enabled, store a cookie on their computer
identifying them.

3. Use the cookies for future logins. Perhaps change the cookie at the
start of each session. Perhaps make this expire.

Alternatively, or if cookies are off, I could require a code, used for one
session only, to be used for a session. The user would enter their email
address. If it matched a list then the code would be sent to the user via
email and they could use it as a password.

Any thoughts? I do not want to make a special mail shot just to give
everyone passwords by mail. Too much effort and cost for too little
reward.

--
http://www.petezilla.co.uk
Mar 9 '06 #1
13 1798
Peter,

You might consider having a single login for the whole club, if the data
you're hiding is not confidential. This will cut down on your coding
time a bit, and you can still use cookies to bypass the login after the
first time. I had a successful outcome doing this on a club site before.

Scott

Peter Chant wrote:
I'm considering setting a website up for a club. I do not plan the contents
to be for public consumption, but on the other hand I'm not going to have
anything on there that is confidential, that would cause a problem if it
went further.

The basic reason is for publicity of club events. I want to make it easy to
use. I suspect a login with a password would be too much effort for most
people. I also note that computer literacy is not a skill all of them
have, the sort of people who have not got the computer skills to be
confident to shop on Amazon.

Basically the problem is communication. Some of them read quarterly
newsletters, some of them bin them. I send the occasional email out with a
list of events, but if I do it too often some of them will start ignoring
them. I have found telephoning people individually to be very successful,
but I am not paid to do it and have a life.

However, I need to be proactive rather than take the curl up and die
approach. For those who are keen on the idea a website might help.

I suspect that security through obscurity is just to lax, a url

http://foo.bar/tbntrjvoprnio/index.html

is just pointless.

My plan is as follows:

1. Make them log in using their email address as a username. Email them
their passwords first.

2. For people who have cookies enabled, store a cookie on their computer
identifying them.

3. Use the cookies for future logins. Perhaps change the cookie at the
start of each session. Perhaps make this expire.

Alternatively, or if cookies are off, I could require a code, used for one
session only, to be used for a session. The user would enter their email
address. If it matched a list then the code would be sent to the user via
email and they could use it as a password.

Any thoughts? I do not want to make a special mail shot just to give
everyone passwords by mail. Too much effort and cost for too little
reward.

Mar 9 '06 #2
Sounds like too much work to me. Both for you and the user. I have
too many passwords to remember already, and if I have to mess with
one-time codes because I don't know how to turn cookies on and off, I
would quickly lose interest in the site. Since confidentiality is not
a real issue, why not just have their email address serve as both logon
and password. Simply have them enter their email on the first page,
check it against the list that you sent email notifications to. If
they are on the list, they are in, otherwise, no access.

Mar 9 '06 #3
Peter Chant wrote:
I'm considering setting a website up for a club. I do not plan the contents
to be for public consumption, but on the other hand I'm not going to have
anything on there that is confidential, that would cause a problem if it
went further.

The basic reason is for publicity of club events. I want to make it easy to
use. I suspect a login with a password would be too much effort for most
people. I also note that computer literacy is not a skill all of them
have, the sort of people who have not got the computer skills to be
confident to shop on Amazon.

Basically the problem is communication. Some of them read quarterly
newsletters, some of them bin them. I send the occasional email out with a
list of events, but if I do it too often some of them will start ignoring
them. I have found telephoning people individually to be very successful,
but I am not paid to do it and have a life.

However, I need to be proactive rather than take the curl up and die
approach. For those who are keen on the idea a website might help.

I suspect that security through obscurity is just to lax, a url

http://foo.bar/tbntrjvoprnio/index.html

is just pointless.

My plan is as follows:

1. Make them log in using their email address as a username. Email them
their passwords first.

2. For people who have cookies enabled, store a cookie on their computer
identifying them.

3. Use the cookies for future logins. Perhaps change the cookie at the
start of each session. Perhaps make this expire.

Alternatively, or if cookies are off, I could require a code, used for one
session only, to be used for a session. The user would enter their email
address. If it matched a list then the code would be sent to the user via
email and they could use it as a password.

Any thoughts? I do not want to make a special mail shot just to give
everyone passwords by mail. Too much effort and cost for too little
reward.

--
http://www.petezilla.co.uk


Well, since the information isn't confidential, why border trying to
protect it? Just have appropriate entries in your robots.txt so Google
doesn't index your site.

Mar 9 '06 #4
Peter Chant wrote:
I'm considering setting a website up for a club. I do not plan the contents
to be for public consumption, but on the other hand I'm not going to have
anything on there that is confidential, that would cause a problem if it
went further.

The basic reason is for publicity of club events. I want to make it easy to
use. I suspect a login with a password would be too much effort for most
people. I also note that computer literacy is not a skill all of them
have, the sort of people who have not got the computer skills to be
confident to shop on Amazon.

Basically the problem is communication. Some of them read quarterly
newsletters, some of them bin them. I send the occasional email out with a
list of events, but if I do it too often some of them will start ignoring
them. I have found telephoning people individually to be very successful,
but I am not paid to do it and have a life.

However, I need to be proactive rather than take the curl up and die
approach. For those who are keen on the idea a website might help.

I suspect that security through obscurity is just to lax, a url

http://foo.bar/tbntrjvoprnio/index.html

is just pointless.

My plan is as follows:

1. Make them log in using their email address as a username. Email them
their passwords first.

2. For people who have cookies enabled, store a cookie on their computer
identifying them.

3. Use the cookies for future logins. Perhaps change the cookie at the
start of each session. Perhaps make this expire.

Alternatively, or if cookies are off, I could require a code, used for one
session only, to be used for a session. The user would enter their email
address. If it matched a list then the code would be sent to the user via
email and they could use it as a password.

Any thoughts? I do not want to make a special mail shot just to give
everyone passwords by mail. Too much effort and cost for too little
reward.

--
http://www.petezilla.co.uk


Well, since the information isn't confidential, why bother trying to
protect it? Just have appropriate entries in your robots.txt so Google
doesn't index your site.

Mar 9 '06 #5
Well, since the information isn't confidential, why border trying to
protect it? Just have appropriate entries in your robots.txt so Google
doesn't index your site.


Well, not confidential as in credit card numbers, but not necessarily
public. Also making it not public deflects some hastle from the people who
think computers are the work of the devil and the internet doubly so. I'm
giving them less excuse to complain. Some people don't give out their
phone numbers on the basis that we'll give them to double glazing companies
and the such like! As if we'd do that. It makes it a real pain in the
arse when we have the need to contact them urgently.

I'm avoiding putting in peoples names and phone numbers (not members,
crucial contacts) but thinking of adding email addresses for contact where
possible, relayed via an alias on my machine to the real address. Either
that or a web form.

Basically if say Fred is running a competition he may not want his name and
telephone number displayed publically on the internet. Whether it is
appropriate on a private web site is a matter for debate.

Basically I want a private web site with as little fuss as possible.

--
http://www.petezilla.co.uk
Mar 10 '06 #6
Scott wrote:
Peter,

You might consider having a single login for the whole club, if the data
you're hiding is not confidential. This will cut down on your coding
time a bit, and you can still use cookies to bypass the login after the
first time. I had a successful outcome doing this on a club site before.


Interesting. Glad to hear it has worked in practice. Maybe combine that
with irimtester's suggestion. I could for a bit more security use email
address and membership number, but that is more hastle for all. Just stick
with email address.

Hmm,

email address as login for first time, match against list.

Cookies for subsequent logins if enabled.

More detailed information, that is sent via the mailing list already, could
be requested via a web form and sent to the (matched) email address.

Thanks,

Pete

--
http://www.petezilla.co.uk
Mar 10 '06 #7
>1. Make them log in using their email address as a username. Email them
their passwords first.

2. For people who have cookies enabled, store a cookie on their computer
identifying them.

3. Use the cookies for future logins. Perhaps change the cookie at the
start of each session. Perhaps make this expire.

Alternatively, or if cookies are off, I could require a code, used for one
session only, to be used for a session. The user would enter their email
address. If it matched a list then the code would be sent to the user via
email and they could use it as a password.

Any thoughts? I do not want to make a special mail shot just to give
everyone passwords by mail. Too much effort and cost for too little
reward.


A bank uses this approach for online banking (overkill for your
purposes, but there are some lessons here):

1. Users already have usernames and passwords assigned for using online
banking. They have also already chosen an image and a title for
that image (the "site key"), and answers to some security questions.

2. User goes to the web site, enters his username, and submits the form.
3. If the computer already has the bank cookie on it for this
account, go to step 6.
4. The user is asked one of the security questions. He's also asked
if this computer is at a secure location. (home or work computer:
maybe secure. internet cafe or library: not secure).
5. The user submits the form. If the info is not correct, go to 4 for
a limited number of tries.
6. A page displays the user's site key (an image and a title for it).
If the user does not see the site key, he has been warned NOT to
enter his password as this may be a spoof site.
7. User enters his password and submits the form.
8. If the password is correct and the computer is at a secure location
(according to the user), the server puts the bank cookie on the computer.
9. The page for online banking is returned.

You probably don't want to go through the whole "site key" thing,
although if there's a chance someone might spoof your site, it could
be worthwhile. Bank spoof sites have become a serious problem.

The point here is that the presence of a cookie can be used to bypass
part of the login sequence, but *LET THE USER SAY WHETHER THE COMPUTER
IS SECURE OR NOT* before putting something on it that lets people
log in as the user. Also it lets people who don't allow cookies
at all in, but they have to go to a little extra trouble.

Perhaps you could allow someone in with the cookie *OR* a password,
but let them ask for the cookie (or not).

Gordon L. Burditt
Mar 10 '06 #8

Peter Chant wrote:
Well, not confidential as in credit card numbers, but not necessarily
public. Also making it not public deflects some hastle from the people who
think computers are the work of the devil and the internet doubly so. I'm
giving them less excuse to complain. Some people don't give out their
phone numbers on the basis that we'll give them to double glazing companies
and the such like! As if we'd do that. It makes it a real pain in the
arse when we have the need to contact them urgently.


Just because a site isn't password-protected doesn't make it "public."
If a site isn't indiced by a search engine, then it's private enough.
It's sort of like keeping your phone number off the telephone book.

My basic point is that people in general don't seek out information
that they don't need. If secrecy isn't required, then it seems
counterproductive to put up a barrier.

Mar 10 '06 #9
Another easy to implement option I have used for a club site is to have
the sensitive stuff (peoples emails, message board) behind one username
and password where i can tell them the username and password on the
login page in language only a club member would get.

For example, The username is the coach's nickname and the password is
the name of his dog.

Kitty
http://www.openskywebdesign.com

Mar 10 '06 #10
Following on from Peter Chant's message. . .
I'm considering setting a website up for a club. I do not plan the contents
to be for public consumption, but on the other hand I'm not going to have
anything on there that is confidential, that would cause a problem if it
went further.


I've just read the 10 or so messages in this thread and here is my
different suggestion.

* You might find it extremely useful to identify (with reasonable
confidence short of definite) who is accessing the site either for
statistics or general policing. eg What do you do if somebody leaves
the club? So one ID per person sounds a good idea.

* You already have some sort of ID system in your membership list. Ie.
some unique tag that you control and doesn't change at the whim of the
member (eg email address can change but club membership number is
fixed.)

* If you email people their access 'code' then that's a reasonably
private thing. The problem you are majoring on is getting people to
type in 'their membership number' [For purposes of discussion I'll
ignore spoofing considerations of using a membership number - you
wouldn't use that.] All you do is email them an address such as
<http://myclub.co.uk/members.php?MbrNo=12345> which is different for
each member.

Your 'index.htm' page is for non-members with a bit linking to how to
access members area (including what if you are a member but unexpectedly
here.)

members.php redirects duff $_GET['MbrNo'] values to the front page.

Your joining instructions go as follows:
1. Go to myclub.co.uk and click on 'I am a member'
2. Enter your name, number, email address and street name
The system then sends you an email informing you how to access the
member's area.
(You log the information for the benefit of the membership sec who can
check street names. The access code is some hash or random number.)
3. Go to the web page indicated in the email AND BOOKMARK IT.
(You might also attempt to set a cookie, that can be fallen back on if
the user goes direct to the main page.)

Can you see what's happened? The access key is in the bookmark and
doesn't rely on cookies or memorising passwords or any typing in.

When a page is accessed with ?MbrNo=12345 you should start it with
"Hello Charlie Smith" just so _everyone knows_ the system has identified
them. If Bots get to index.htm then that's great 'cos you presumably
want to let non-members know of your Good Works. But make sure there is
no link between index.htm and members.php (even if members.php is botted
all that happens is a redirect to index.htm 'cos no bot will know the
?MbrNo bits required.
--
PETER FOX Not the same since the borehole business dried up
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>
Mar 10 '06 #11
In article <11**********************@z34g2000cwc.googlegroups .com>,
ch***********@hotmail.com (Chung Leong) wrote:
Just because a site isn't password-protected doesn't make it "public."
If a site isn't indiced by a search engine, then it's private enough.
It's sort of like keeping your phone number off the telephone book.


But do remember that blocking with robots.txt only keeps out spiders which
obey the rules. Spammers' spiders are out to steal whatever they can, and
may regard robots exclusions as a 'good stuff here!' flag. So you still
need to disguise any personal information :-(

--
To reply email rafe, at the address cix co uk
Mar 10 '06 #12
Gordon Burditt wrote:


You probably don't want to go through the whole "site key" thing,
although if there's a chance someone might spoof your site, it could
be worthwhile. Bank spoof sites have become a serious problem.

I don't see spoofing to be a problem, there is no financial gain. I was not
expecting to put any information up, except 'Hello Fred' that would differ
from user to user.
The point here is that the presence of a cookie can be used to bypass
part of the login sequence, but *LET THE USER SAY WHETHER THE COMPUTER
IS SECURE OR NOT* before putting something on it that lets people
log in as the user. Also it lets people who don't allow cookies
at all in, but they have to go to a little extra trouble.

Perhaps you could allow someone in with the cookie *OR* a password,
but let them ask for the cookie (or not).


So you are saying, use a login but give them the option of using cookies
only if they are enabled.

Pete
--
http://www.petezilla.co.uk
Mar 13 '06 #13
Peter Fox wrote:

I've just read the 10 or so messages in this thread and here is my
different suggestion.
Cheers

* You might find it extremely useful to identify (with reasonable
confidence short of definite) who is accessing the site either for
statistics or general policing. eg What do you do if somebody leaves
the club? So one ID per person sounds a good idea.
Yes

* You already have some sort of ID system in your membership list. Ie.
some unique tag that you control and doesn't change at the whim of the
member (eg email address can change but club membership number is
fixed.)
Yes, it is a database ran by myself. This will not be linked to the
internet. _I_ use an id number system that does not change. Don't get me
started on the membership number system someone else uses that changes on a
yearly basis as they renew and / or mid year when they realised they
recorded a payment out of sync...

* If you email people their access 'code' then that's a reasonably
private thing. The problem you are majoring on is getting people to
type in 'their membership number' [For purposes of discussion I'll
ignore spoofing considerations of using a membership number - you
wouldn't use that.] All you do is email them an address such as
<http://myclub.co.uk/members.php?MbrNo=12345> which is different for
each member.

Good plan. Looking at the above a random number per user with a reasonable
length should do the trick. It would be difficult to guess the access
numbers on that basis. Easy on my separate membership database to
generate, via a cron job an access list:

tom,genovhvowvbuor
dick,riovnioniovnio
harry,hgioevneioerr

etc
Your 'index.htm' page is for non-members with a bit linking to how to
access members area (including what if you are a member but unexpectedly
here.)

members.php redirects duff $_GET['MbrNo'] values to the front page.

I'm thinking maybe about having just one page, index.php and using
variables, a switch statement and 'include' to produce each page.
<http://myclub.co.uk/members.php?MbrNo=12345&page=calender>
I only want half a dozen pages at best so this keeps authentication nice and
simple.

Your joining instructions go as follows:
1. Go to myclub.co.uk and click on 'I am a member'
2. Enter your name, number, email address and street name
The system then sends you an email informing you how to access the
member's area.
(You log the information for the benefit of the membership sec who can
check street names. The access code is some hash or random number.)
3. Go to the web page indicated in the email AND BOOKMARK IT.
(You might also attempt to set a cookie, that can be fallen back on if
the user goes direct to the main page.)

Can you see what's happened? The access key is in the bookmark and
doesn't rely on cookies or memorising passwords or any typing in.
Yes, that is simple and aviods cookies. I'm not going to register anyone
via the website at the moment. Just keep it simple, they can email me.

When a page is accessed with ?MbrNo=12345 you should start it with
"Hello Charlie Smith" just so _everyone knows_ the system has identified
them.
Useful & friendly.
If Bots get to index.htm then that's great 'cos you presumably
want to let non-members know of your Good Works. But make sure there is
no link between index.htm and members.php (even if members.php is botted
all that happens is a redirect to index.htm 'cos no bot will know the
?MbrNo bits required.


Only really intending this as a limited thing to give members the chance to
pull information from a website rather than wait until I send it out on a
mailing list, at least for the moment.

Thanks to all who have responded in this thread, it was useful and probally
has saved me time by avoiding making things overcomplicated.

Pete

--
http://www.petezilla.co.uk
Mar 13 '06 #14

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Mark Hanford | last post by:
The Why: I'm in the process of creating a Linux+Apache+PHP website with a public area and an admin area for configuration and updates. The What: One of the features of the admin area is...
3
by: Darren | last post by:
Please Help Me!! I've created a typical <form> and a <select> element. The options are created dynamically from my access database (using asp). There are about 70 options, and when you click...
1
by: Daniel | last post by:
limiting access to files with asp.net is there any way i can make a file only accessible to certain users of my website? my files are to large to copy to a temp directory and they are of many...
2
by: Jo Davis | last post by:
access fe and access be. later the be might be sql server I don't want people to pass this application around. And I want control over usage. I want it to 'expire' after a while. I have fairly...
5
by: randyelliott | last post by:
Good Day, I have a MS Access (Access 2000 now upgraded to 2003) database that tracks customer information. One function of this database is to create an encrypted license file for our software,...
4
by: N J | last post by:
Hi, I ahve developed a program using access and am distributing it using MDE's, I ahve had many requests for a demo. I was thinking of limiting the number of records to say 100? If anyone has...
2
by: Mezzrow | last post by:
Firstly, I apologize if this question has been already answered. I have been searching for a while and haven't found anything. I am building a system where two servers need to exchange messages...
8
by: integravtec | last post by:
Hey guys, I'm new here. Just had a question, so I want to thank you in advance for the help. I not too familiar with programming other languages than Html, dhtml, and javascript. So I figured there...
2
by: prakashwadhwani | last post by:
I've used Dbase/Clipper for years & Access for a little while now but Access doesn't seem to have any elegant solution to limiting the size of a text box ... i.e. the max number of characters that...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.