Suggestions wanted for non-logged-in user in closed beta pha

Will shortly be deploying first iteration of app to some beta testers
(i.e. friends), and want them to be able see it both from logged-in view
and guest (i.e. not logged-in) view. The two are a fair bit different.
It’s a closed beta, so (hopefully) no pages (other than a blank login
page) will be visible.

The question is, what’s the best way for them to be able to see (and
test) the app in guest mode. Have two layers of auth (the app’s and an
external one), set up a group role that simulates guest access (not wild
about this since it will mean changing the ACL setup after it’s done).

Any other ideas, opinions?

Chris T wrote:

Will shortly be deploying first iteration of app to some beta testers
(i.e. friends), and want them to be able see it both from logged-in view
and guest (i.e. not logged-in) view. The two are a fair bit different.
It’s a closed beta, so (hopefully) no pages (other than a blank login
page) will be visible.

The question is, what’s the best way for them to be able to see (and
test) the app in guest mode. Have two layers of auth (the app’s and an
external one), set up a group role that simulates guest access (not wild
about this since it will mean changing the ACL setup after it’s done).

Any other ideas, opinions?

No-one?

On 8-Jun-06, at 12:39 PM, Chris T wrote:

test) the app in guest mode. Have two layers of auth (the app’s
and an
external one), set up a group role that simulates guest access
(not wild
about this since it will mean changing the ACL setup after it’s
done).

Any other ideas, opinions?

No-one?

Hi Chris,

it’s kind of a vague question that requires an answer specific to
your code :slight_smile:

Have you considered using basic-auth at the webserver level to
protect access to the site as a whole with a beta-site access password?

Regards,
Trevor


Trevor S.
http://somethinglearned.com

Trevor S. wrote:

The question is, what’s the best way for them to be able to see (and
Hi Chris,

it’s kind of a vague question that requires an answer specific to your
code :slight_smile:

Have you considered using basic-auth at the webserver level to protect
access to the site as a whole with a beta-site access password?

Regards,
Trevor
Yup, that’s what I was thinking of when I said two layers of auth. Not
terribly elegant or pretty though. I guess I just put the htdigest file
in the public directory?

On 8-Jun-06, at 2:56 PM, Chris T wrote:

Trevor
Yup, that’s what I was thinking of when I said two layers of auth.
Not terribly elegant or pretty though. I guess I just put the
htdigest file in the public directory?

Well, it’s been years since I did basic-auth so I can’t say off the
top of my head - likely it’ll be specific to your webserver.

Regards,
Trevor

Trevor S.
http://somethinglearned.com

Chris,

I recently had a similar situation and solved it simply this way.
Basically it’s just another filter layer that

— [ environment.rb ] —

module YOUR_APP
PREVIEW_KEY = ‘your_app_007’
end

— [ application.rb ] —

class ApplicationController < ActionController::Base

def ensure_covertness
return true if request.env[‘SERVER_NAME’].nil? ||
request.env[‘SERVER_NAME’].include?(‘localhost’)
if session[:preview_key] != YOUR_APP::PREVIEW_KEY
redirect_to :controller => ‘index’, :action => ‘preview’ and
return false
else
true
end
end

end

— [ index_controller.rb ] —
class IndexController < ApplicationController

before_filter :ensure_covertness, :except => :preview

def preview
if request.post? && params[:code] == YOUR_APP::PREVIEW_KEY
session[:preview_key] = YOUR_APP::PREVIEW_KEY
redirect_to :action => ‘index’
else
render :layout => false
end
end

end

— [ preview.rhtml ] —

Preview

<%= start_form_tag %>
<%= password_field_tag ‘code’ %>
<%= submit_tag ‘Submit’ %>
<%= end_form_tag %>

Now put this line in every controller as the first line or better yet
in a base PublicController (for your public pages) and
SecureController for those pages where the user must be logged in.

before_filter :ensure_covertness

Hope this helps,
Zack