# Authentication: is a guest a user or an "exception"?

**URL:** <https://www.ruby-forum.com/t/authentication-is-a-guest-a-user-or-an-exception/119264>\
**Category:** Rails\
**Created:** [November 5, 2007, 5:22pm UTC](https://www.ruby-forum.com/t/authentication-is-a-guest-a-user-or-an-exception/119264 "2007-11-05T17:22:15Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![josh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/45deac/32.png) [@josh](https://www.ruby-forum.com/u/josh)\
**Post date:** [November 5, 2007, 5:22pm UTC](https://www.ruby-forum.com/t/authentication-is-a-guest-a-user-or-an-exception/119264/1 "2007-11-05T17:22:15Z")

</div>

Hi all

I’m currently implementing authentication/authorization in my app. Now  
I’m wondering what’s the common way to handle a guest…

In fact, many of the visitors of my app will be anonymous users that  
just want to read articles etc., but one can register as a member to  
have some further possibilities. So far one can login as a member and  
from this point on one has rights on the app, depending on the groups  
one is assigned to.

So far, so good.

But what’s with the anonymous users now? How do I handle them on pages  
that can be seen by anonymous users AND registered users?

Let me present an example where I want to greet the user and show him  
how many unread private messages he has…

* * *

Alternative 1: guests do not really exist, they are handled in the view  
code (view code knows that there’s a difference between guests and  
logged in users and checks accordingly)

Hello \<%= member\_logged\_in? ? member.nickname : ‘Guest’ %\>!  
\<%= “You have #{member.private\_messages.find\_by\_status(:unread)} unread  
PM’s” if member\_logged\_in? %\>

While the member function looks something like that:

def member  
Member.find\_by\_id(session[:member\_id])  
end

* * *

Alternative 2: the guest user exists in the database (with the nickname  
“Guest”) like any other user and is automatically treated as logged in,  
as long as the visitor doesn’t explicitly login himself

Hello \<%= member.nickname %\>!  
\<%= “You have #{member.private\_messages.find\_by\_status(:unread)} unread  
PM’s” if member\_logged\_in? %\>

While the member function looks something like that:

def member  
session[:member\_id] ? Member.find\_by\_id(session[:member\_id]) :  
Member.find\_by\_id(1) # The ID 1 identifies the guest user in the  
database  
end

* * *

Alternative 3: guests do not really exist in the database, but they are  
handled in the helper methods (view code does not know any difference  
between guests and logged in users)

Hello \<%= member.nickname %\>!  
\<%= “You have #{member.private\_messages.find\_by\_status(:unread)} unread  
PM’s” if member\_logged\_in? %\>

While the member function looks something like that:

def member  
session[:member\_id] ? Member.find\_by\_id(session[:member\_id]) :  
Member.new(:nickname =\> “Guest”)  
end

* * *

Well, let me brainstorm about some pros (+) and cons (-) of the  
different alternatives…

Alternative 1:

- (None?)

- It’s annoying to always check in the view and manually hardcode stuff  
about the pseudo member “Guest”

Alternative 2:

- There has to be a standard “Guest” member ready and set up with a  
unique ID, although guests aren’t really “one member”
- One will always have to filter this standard “Guest” member out of  
queries that should only affect “real” members (for a statistic called  
“Member with the most page hits” it would be unfair to have the user  
“Guest” at the top of the list, wouldn’t it?)
- One has to check manually e.g. if the member can edit his details  
(signature and stuff), because it wouldn’t make sense that guests have a  
signature and stuff

- The view code does not have to know anything about the difference  
between guests and logged in members
- One can manage (assign rights etc.) guests the same way as any other  
user
- All dynamic finder stuff etc. in Rails can be fully used, e.g. one can  
create statistics for the guest user
- Foreign keys can be set e.g. for comments that can be written by  
guests AND members (no need to allow NULL in database fields like  
creator\_id)

Alternative 3:

- One can’t read statistics for the guest user out of the database as  
one can in Alternative 2
- Foreign keys can’t be set as it is possible in Alternative 2

- The view code does not have to know anything about the difference  
between guests and logged in members
- One can manage (assign rights etc.) guests the same way as any other  
user, although one has to do this manually anytime when creating the  
Member(:nickname =\> “Guest”)

At the moment I’m clearly tending to choose between Alternative 2 and  
3… but I’m quite unsure which one to take. Both have advantages and  
disadvantages. Alternative 2 seems the most compelling, but maybe I  
don’t see all the impacts, restrictions etc. of the three different  
alternatives? And what ID should I take for the “Guest” user? ID#2,  
right after the Webmaster member? ID#0 to indicate that it isn’t really  
a member? I know, that’s really not very important, but I like eye  
candy… 😉

(Anyway, for alternative 2 and 3 the member() function might better be  
named user(), just for semantical correctness (a “user” is just somebody  
that uses the site; while a “member” points too much in the direction  
that the user has logged in already)… just a thought.)

I’d be glad to here some opinions about this topic from you guys. 🙂

Thanks a lot  
Josh