2011-08-09 3 views
1

Je suis tombé sur un problème en matière de redirection derrière un ensemble protégé d'URL (section admin) dans une application Sinatra. C'est probablement une erreur stupide, mais je n'ai rien trouvé en ligne qui aide.Problème d'authentification de publication/redirection avec Sinatra

Ceci est pour une zone protégée par mot de passe comme le montrent les aides, où l'utilisateur peut créer de nouveaux événements. La première fois qu'un utilisateur tente d'accéder à l'administrateur, ils sont invités à entrer un mot de passe, puis les pages suivantes sont laissées. Le problème que j'ai, c'est que lorsque l'application tente de rediriger après un nouvel événement réussi, l'utilisateur doit se ré-authentifier ... ce qui semble peu redondant.

Cela s'applique également pour le processus de suppression et d'édition, l'utilisateur est toujours invité lorsque une redirection est tentée. J'ai essayé passer au deuxième paramètre à un code HTTP différent, mais en vain

Quoi qu'il en soit, voici le code, des questions/aide serait appréciée

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 

Répondre

0

Est-ce que passe-t-il à Safari?

J'ai utilisé le code ci-dessus et seules les ré-authentifications dans Safari, Chrome et FireFox fonctionnent comme prévu.

Il semble que si vous vérifiez le "se souvenir de mon nom d'utilisateur/mot de passe" Safari enverra chaque demande subséquente sans l'autorisation dans l'en-tête (un excellent outil pour regarder les en-têtes etc est Charles). Si vous le vérifiez, Apple envoie l'Auth dans l'en-tête correctement et même si vous quittez Safari, il continuera à penser à envoyer l'Auth lors de la relance.

Il est donc stupide d'Apple ne vous :)

+0

Pour contourner ce problème, vous pouvez utiliser l'authentification par cookie http://ididitmyway.heroku.com/past/2011/2/22/really_simple_authentication_in_sinatra/ un cookies étant bonus peut être réglé pour expirer là où l'authentification de base HTTP ne se ferme qu'à la fermeture (ou uniquement via l'accès Keychain Access de Safari). – kreek

+0

Ah putain, c'est une honte, merci de regarder si, oui, il fonctionne un régal dans Chrome et FF. C'est seulement interne donc je vais passer un peu de temps à les regarder en les laissant penser – redroot