2008-11-21 13 views
1

Actuellement, nous nous stockons le HTTP_REFERER de l'utilisateur afin que nous puissions rediriger l'utilisateur vers la page précédente, ils broutaient avant connecté.Est-il préférable d'utiliser HTTP REFERER pour les redirections ou d'utiliser une autre méthode?

Http Referer vient du client et peut être usurpée ou vide. Existe-t-il une méthode plus sûre/fiable pour fournir cette redirection utilisateur pratique?

+0

Ma mentalité à chaque fois que je l'utilise, c'est que si quelqu'un usurpe son référent alors je ne me soucie pas vraiment de savoir s'ils reviennent d'où ils viennent. Je crois que 99% du temps, il sera disponible et correct. Les 1% sont des utilisateurs avancés qui retrouveront leur chemin de toute façon. –

+0

Je me souviens du jour où, tout à coup, la moitié du web a été brisée. Il s'est avéré Norton (ce bâtard) enlevait tous les renvois de mes messages ou obtient. J'étais tellement énervé ... – Will

Répondre

2

Avez-vous des séances?

Si c'est le cas, vous pouvez suivre du côté serveur les pages auxquelles ils ont accédé dans cette session et les renvoyer à la page précédente.

(caching pourrait gâcher tout ça, mais vous pouvez définir le cache-control: appropriée)

Mais tout cela semble plus de douleur que le gain. Y a-t-il un vrai problème à les renvoyer sur une page usurpée, s'ils sont assez stupides pour le faire?

Paul.

2

en cours d'exécution en quelque sorte

est la seule alternative que je peux penser (javascript)

0

Habituellement, je le passe avec le formulaire de connexion.

<form action="login" method="post"> 
<input type="hidden" name="url" value="... whatever the current url is ..."> 
<input type="text" name="username"> 
<input type="text" name="password"> 
</form> 
+0

Et comment saurez-vous quelle page était-ce? Oh, vous supposez que la page de connexion est sur un site différent. –

+0

Je supposais que la boîte de connexion était sur chaque page du site, donc vous pouvez naviguer sur le site non connecté, mais connectez-vous à partir de n'importe quelle page et retournez à la page où vous étiez – Greg

+0

Hmmm, il semble que nous avons besoin de plus le contexte. J'ai interprété qu'il voulait renvoyer l'utilisateur à, disons, google.com –

0

Pas que je sache. Mais alors, est-ce que vous supposez que les utilisateurs normaux seront autour de feindre leur Referer juste pour être redirigé au mauvais endroit? Cela semble improbable.

Je m'inquiète de la nécessité de rediriger les utilisateurs d'où ils viennent sans même les interroger. Je serais soit avoir une option de préférences pour décider de l'autoriser ou non (et où), ou leur demander précédemment à la redirection, être capable de refuser la redirection. Si RoBorg suppose que vous proposerez des écrans de connexion sur des sites différents des vôtres et que vous souhaitez stocker le site source, vous pouvez bien entendu utiliser le même formulaire pour envoyer le site depuis lequel vous vous êtes connecté.

0

Le referer fonctionnerait probablement bien pour la majorité des utilisateurs, bien que je suppose que vous deviez vérifier XSRF. Ce que nous faisons est, quand quelqu'un frappe une zone où ils doivent se connecter, ils sont redirigés vers le paeg de connexion avec l'URL de l'endroit où ils ont été stockés dans la session. Une fois qu'ils sont connectés, ils sont redirigés vers l'URL précédente.

Bien sûr, cela dépend beaucoup de la configuration de votre authentification!

0

J'ai réellement une fonction qui utilise plusieurs méthodes différentes pour rediriger en fonction du chemin que l'utilisateur a pris pour se rendre à la page de connexion.

La fonction que j'appelle après l'utilisateur se connecte en ressemble à:

Protected Sub doRedirect(ByVal sender As Object, ByVal e As System.EventArgs) 
    If Not Request.QueryString("rtn") Is Nothing Then 
     Response.Redirect(Request.QueryString("rtn").ToString) 
    ElseIf Me.hidden_return.Value <> "" Then 
     Response.Redirect(Me.hidden_return.Value) 
    ElseIf Not Request.UrlReferrer Is Nothing AndAlso Request.UrlReferrer.Segments(Request.UrlReferrer.Segments.Length - 1) <> "login.aspx" Then 
     Response.Redirect(Request.UrlReferrer.ToString) 
    Else 
     Response.Redirect("default.aspx") 
    End If 
End Sub 

Il est évident que tout cela pourrait être usurpée sur les clients finaux, mais je ne se soucient pas vraiment s'ils veulent s'usurper.

Questions connexes