Question

I’ve stumbled across a bit of problem when it comes to redirects behind a protected set of URLs (admin section) within a Sinatra app. It most likely a silly mistake but I haven’t found anything online that helps.

This is for a password protected area as the helpers show, where the user can create new events. The first time a user tries to access the admin, they are prompted for a password, then subsequent pages are left. The problem I have is that when the app attempts to redirect after a successful new event is made, the user has to re-auth themselves … which seems bit redundant.

This also applies for the deletion and editing process, the user always gets prompted when a redirect is attempted. I’ve tried passing 303 at the second parameter to for a different HTTP code, but to no avail

Anyway, here’s the code, any questions/help would be appreciated

helpers do
    def protected!
      unless authorized?
         response['WWW-Authenticate'] = %(Basic realm="Restricted Area")
         throw(:halt, [401, "Not authorized\n"])
      end
    end

    def authorized?
        @auth ||=  Rack::Auth::Basic::Request.new(request.env)
        @auth.provided? && @auth.basic? && @auth.credentials && @auth.credentials == ['admin', 'admin']
    end
end
...
get "/admin/events/:id" do
    protected!
    conf = Conference.where(:_id => params[:id]).first
    not_found unless conf
    haml :admin_event_edit, :layout => :admin_layout, :locals => { :event => conf }
end

post "/admin/events/new/" do
   protected!
   conf = Conference.new(params[:event])
   if conf.save!
      redirect "/admin/events/" 
   else
      "Something went horribly wrong creating the new event, heres the form contents #{params.inspect}"
   end
end

get "/admin/events/" do
   protected!
   haml :admin_events, :layout => :admin_layout, :locals => { :our_events => Conference.where(:made => true).order_by(:start_date.asc).limit(15), :other_events => Conference.where(:made => false).order_by(:start_date.asc).limit(15)}
end

Answer 1

Is this only happening in Safari?

I’ve used the code above and it only re-auths in Safari, Chrome, and FireFox work as expected.

It seems that if you unless you check the “remember my username/password” Safari will send each subsequent request without the Authorization in the header (a great tool for watching headers etc is Charles). If you do check it then Apple sends the Auth in the header correctly and even if you quit out of Safari it will continue to remember to send the Auth on relaunch.

So it’s Apple being silly not you 🙂