banbanfr
Messages postés132Date d'inscriptiondimanche 8 janvier 2006StatutMembreDernière intervention15 février 2011 23 juil. 2008 à 00:27
Je l'ai installé et testé depuis un moment le seul avantage de ce genre appli (application, logiciel) c'est d'avoir un raccourcis sur son bureau et effectivement d'avoir le minimum requit pour naviguer sur le net.Je ne critique pas, je donne juste mon opinion :). Je l'ai testé pour l'utiliser avec : www.dematplus.fr un site que j'ai fait pour fournir à certain clients une sorte d'application qui pointe directement vers ce site mais le problème, c'est que je devais leur demander à tous de télécharger Prism pourtant quand tu ouvres Prism et lui fournie les informations du site à utiliser, un fichier .app est généré (genre il a fabriquer une application tonsite.app) et donc pensais que cela suffisait pour mes clients ce qui n'est en faite pas le cas :
ralecul
Messages postés111Date d'inscriptiondimanche 23 mars 2003StatutMembreDernière intervention 1 août 2008 23 juil. 2008 à 00:01
Il faut installer Prism pour l'utiliser ça c'est clair ;-)
Après je ne comprend pas ta remarque : qu'est-ce que tu appelles appli ?
S'il s'agit du site web que tu consultes via Prim -> ça marche avec gmail donc pas besoin d'héberger le site localement.
S'il s'agit du raccourci sur le bureau que tu créé ça peut se déployer facilement dans le cadre d'un usage interne (intranet).
Sinon ben j'ai pas compris...
Dans tous les cas je te conseille de l'installer juste pour voir, tu verras que c'est assez facile de créer des raccourcis (appli ?).
banbanfr
Messages postés132Date d'inscriptiondimanche 8 janvier 2006StatutMembreDernière intervention15 février 2011 22 juil. 2008 à 23:36
Le problème de Prism c'est qu'il faut avoir l'appli car si tu fournis a quelqu'un un fichier générer, il ne pourra rien en faire sauf s'il télécharge a son tour prism. peut etre une solution en java pour embarquer l'ensemble (fichier+appli)
ralecul
Messages postés111Date d'inscriptiondimanche 23 mars 2003StatutMembreDernière intervention 1 août 2008 22 juil. 2008 à 23:25
Dans le cadre d'une utilisation pour un intranet il existe une autre solution :
Installer Prism (anciennement Xulrunner, http://labs.mozilla.com/2007/10/prism/) encore en Beta malheureusement.
Prism permet en gros d'avoir un Firefox sans bouton de navigation et de barre d'adresse.
Bien sur si c'est pour une utilisation autre qu'un intranet cela ne peut pas convenir.
Et je reviens au questionnement portant sur l'utilité de la chose.
cs_Martin72
Messages postés6Date d'inscriptionjeudi 26 juin 2008StatutMembreDernière intervention19 juillet 2008 19 juil. 2008 à 19:15
Merci pour les commentaires. Je voudrais ajouter ceci.
- Sur ce site (http://www.javascriptfr.com), il s'agit, en principe, de ne proposer que des solutions javascript.
- Le mot "sécurisé" est maladroit car ce script ne sécurise rien. Je voulais dire que, sauf réelle nécessité, il devrait être exclu des sites web publics. Il provoque des réactions très négatives chez les visiteurs.
- Certaines applications ne peuvent pas se contenter d'une solution aussi simple.
- Un avertissement "noscript" est bien sûr très utile.
- Ce petit script ne fait aucun appel au serveur : il s'agit d'une opération locale interne, utilisant le cache du navigateur du client.
- Le script résout le cas de Firefox : depuis la version 1.5 (fin 2005), son cache se comporte différemment. Voir, entre autres, la doc sur
http://developer.mozilla.org/fr/docs/Utilisation_du_cache_de_Firefox_1.5. - Il n'y a aucun moyen de supprimer le bouton back du navigateur du client mais seulement de le neutraliser. Même en ouvrant une fenêtre sans menu, il reste la touche "retour" du clavier.
- Enfin, comme un bon exemple vaut mieux que de longues explications, j'invite les amateurs à une petite démo sur
http://users.skynet.be/mj/noback/page_1.html
Cordialement.
cs_bultez
Messages postés13615Date d'inscriptionjeudi 13 février 2003StatutMembreDernière intervention15 octobre 201330 19 juil. 2008 à 14:12
bonjour à toutes et à tous,
"intéressant"
- location.replace peut parfois remplacer
- <noscript>au cas où</noscript>
peut "obliger" le javascript, le signaler...
- on peut gérer coté serveur
- on peut tester d'où on vient dans la
"page précédente"
- concevoir l'application "autrement"
et en fait... tout est là !
...
j'avais déjà vu ça, je ne suis pas le seul je pense ?
ça peut être utile dans certains contextes
( sans parler d'autre chose que d'éviter
les fausses manips d'un utilisateur )
en plus de l'aspect codage pas si simple.
bref... utile et intéressant :
la preuve : le nombre d'interventions.
Cordialement.
banbanfr
Messages postés132Date d'inscriptiondimanche 8 janvier 2006StatutMembreDernière intervention15 février 2011 18 juil. 2008 à 10:10
Merci :)
FREMYCOMPANY
Messages postés276Date d'inscriptionjeudi 12 janvier 2006StatutMembreDernière intervention22 décembre 2008 18 juil. 2008 à 10:08
Pour tromper le bouton suivant, il y a toujours une solution à base d'une IFRAME que l'on fait changer d'adresse et dont la première page "autoforward" vers la suivante. Ainsi, c'est juste l'iframe invisible qui change de page, et le contenu de la page principale n'est pas perdu.
banbanfr
Messages postés132Date d'inscriptiondimanche 8 janvier 2006StatutMembreDernière intervention15 février 2011 18 juil. 2008 à 03:54
Je trouve que cela peut être utile mais dans quel cas ?? là je sais pas.
Par contre, s'il y a une solution pour désactiver réellement le bouton précédent (et non un va et revient) je suis preneur (dans le cas d'une appli ajax cela peut être utile) car on voit bien que le navigateur repart vers B mais revient vers C aussi tôt ce qui est équivaut a 2 chargements au final.
Sinon c'est une bonne initiative!
Cordialement
lakichemole
Messages postés253Date d'inscriptionvendredi 13 juin 2003StatutMembreDernière intervention18 mai 2009 17 juil. 2008 à 12:22
meaculpa j'avais pas bien compris son script, alors en effet c'est pas top^^, l'utilisation des header et l'expiration de la page est pas mal :)
youspim
Messages postés21Date d'inscriptionjeudi 23 mars 2006StatutMembreDernière intervention17 juillet 2008 17 juil. 2008 à 11:45
Personnellement j'utilise plutôt location.replace dés que je peut car cela permet d'écraser la dernière entrée de l'historique plutôt que d'en rajouter une et de ce fait il est impossible de revenir la page précédente.
Peut être que la vrais bonne technique c'est de combiner toutes ces méthodes selon la situation et du réel besoin que l'on a.
Enfin, je précise que ce genre de pratique n'est pas destiné a des pages web normales, c'est à réserver à un usage pour applications internes (publique restreins et avisé).
Merci pour la contribution ;-)
jantosze
Messages postés72Date d'inscriptionmercredi 29 mai 2013StatutMembreDernière intervention15 mai 2009 17 juil. 2008 à 11:42
Le script de Martin72 est prévu dans un cas (si j'ai compris) de navigation:
je suis sur un site en page A je vais vers B puis vers une page sécurisée C, dans le cas d'un BACK, il n'y a pas de retour sur B mais uniquement sur A, sur C ou une autre page que B. Exemple de mise en oeuvre PHP sur le tuto de
http://www.phpfrance.com/tutoriaux/index.php/2006/09/27/45-comment-rediriger
En fait, on ne neutralise pas la touche BACK mais on joue sur la redirection.
tombeduciel
Messages postés3Date d'inscriptionsamedi 29 avril 2006StatutMembreDernière intervention17 juillet 2008 17 juil. 2008 à 11:41
g crée une application de gestion de stock sur access pour la gestion des téléphonies mobiles ,des entées et des sorties avec etat de stock, mon probléme:comment pourrai-je faire pour établir un état de tous les articles que g de tell date à tell date et les quantités livrée de tell date à telle date on calculant la somme des articles sortant dans cette période?
tombeduciel
Messages postés3Date d'inscriptionsamedi 29 avril 2006StatutMembreDernière intervention17 juillet 2008 17 juil. 2008 à 11:30
slt martin72 cque tu as proposé est meilleur:et pour les autres je leur dis :la meilleure façon pour éliminer une suggestion il faut en proposer une meilleure et merci
lakichemole
Messages postés253Date d'inscriptionvendredi 13 juin 2003StatutMembreDernière intervention18 mai 2009 17 juil. 2008 à 11:19
Je pense que si on utilise cette méthode avec un site intranet (dont on control les versions et les composants des browser utilisateur) cela peut être très utile.
Et comme le dis si bien Martin72 rien de mieu est proposé à priori (testé je veux dire).
Concernant les header et l'expiration de la page ce serait pas mal de tester en effet mais à mon avis le résultat ne sera pas qu'on ne peut pas revenir en arrière et donc pas la même chose.
Concernant le fait de faire la même chose en PHP donc coté serveur il est évident que le site doit gérer le fait de revenir à la page précédente mais le php n'empèchera/limitera pas à mon avis l'utilisation du cache client et le click du bouton précédent qui est purement client.
Enfin je pense que l'idéal pour ce genre de script c'est pour un site entièrement fait en flash (comme deezer) tu fait une recherche dans google tu click sur l'url du site tu arrive sur le site tu commence à utiliser l'appli flash et sans faire exprès tu click sur précédent (ou tu appuis sur backspace) résultat tout se que tu as fait dans l'appli flash est perdu et tu te retrouve sur ta recherche google.
Avec l'utilisation de ce script cela évitera les erreur de manipulation.
jantosze
Messages postés72Date d'inscriptionmercredi 29 mai 2013StatutMembreDernière intervention15 mai 2009 17 juil. 2008 à 10:16
Salut,
Dans le cadre d'une page nécessitant JS, pourquoi pas, mais jouer la carte sécurité unique sur une fonction JS j'ai des doutes. J'envisagerai une solution PHP par exemple.
cs_Martin72
Messages postés6Date d'inscriptionjeudi 26 juin 2008StatutMembreDernière intervention19 juillet 2008 16 juil. 2008 à 15:51
Ma foi, tant que personne n'en propose de meilleure...
runinho
Messages postés43Date d'inscriptionmardi 15 juillet 2008StatutMembreDernière intervention10 juillet 2010 16 juil. 2008 à 15:27
Comme fremycompany l'a dis c une movaise solution
FREMYCOMPANY
Messages postés276Date d'inscriptionjeudi 12 janvier 2006StatutMembreDernière intervention22 décembre 2008 16 juil. 2008 à 12:32
Les headers permettent de faire expirer un page très rapidement et d'empêcher sa mise en cache. Dans de telles conditions, l'appui sur le bouton précédent devrait (je n'ai pas testé tous les navigateurs car je n'ai encore jamais appliqué cette technique) ne plus s'afficher et être remplacée par un message d'erreur "La page a expiré". Enfin, cela n'est vrai que si la page a reçu des données par POST, il me semble. C'est en tout cas à vérrifier.
Sinon, je voulais quand même ajouter quand ton code marche normalement assez bien pour l'utilisateur non-averti.
cs_Martin72
Messages postés6Date d'inscriptionjeudi 26 juin 2008StatutMembreDernière intervention19 juillet 2008 16 juil. 2008 à 12:25
Bien sûr, si le retour à la page précédente constitue un réel danger, cela ne suffit pas.
Plutôt que "interdire" et "obliger", il vaudrait mieux écrire "empêcher" et "convaincre".
Quelle est ta solution via headers ?
FREMYCOMPANY
Messages postés276Date d'inscriptionjeudi 12 janvier 2006StatutMembreDernière intervention22 décembre 2008 16 juil. 2008 à 11:24
C'est une mauvaise solution.
Car si JavaScript est désactivé, ton visiteur accédera quand même à la page.
Disons que cela peut être une manière de le faire comprendre au visiteur, mais le serveur devra, lui, toujours gérer les "retours arrières" possibles du surfeur.
Mieux vaut faire expirer la page via les headers, par exemple.
23 juil. 2008 à 00:27
Voilà le contenu du package générer :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<dict>
<key>CFBundleExecutable</key>
<string>DEMAT Plus</string>
<key>CFBundleIconFile</key>
<string>app.icns</string>
</dict>
et :
#!/bin/sh
exec /Applications/Prism.app/Contents/MacOS/xulrunner -webapp demat.plus@prism.app
Cordialement ;)
23 juil. 2008 à 00:01
Après je ne comprend pas ta remarque : qu'est-ce que tu appelles appli ?
S'il s'agit du site web que tu consultes via Prim -> ça marche avec gmail donc pas besoin d'héberger le site localement.
S'il s'agit du raccourci sur le bureau que tu créé ça peut se déployer facilement dans le cadre d'un usage interne (intranet).
Sinon ben j'ai pas compris...
Dans tous les cas je te conseille de l'installer juste pour voir, tu verras que c'est assez facile de créer des raccourcis (appli ?).
22 juil. 2008 à 23:36
22 juil. 2008 à 23:25
Installer Prism (anciennement Xulrunner, http://labs.mozilla.com/2007/10/prism/) encore en Beta malheureusement.
Prism permet en gros d'avoir un Firefox sans bouton de navigation et de barre d'adresse.
Bien sur si c'est pour une utilisation autre qu'un intranet cela ne peut pas convenir.
Et je reviens au questionnement portant sur l'utilité de la chose.
19 juil. 2008 à 19:15
- Sur ce site (http://www.javascriptfr.com), il s'agit, en principe, de ne proposer que des solutions javascript.
- Le mot "sécurisé" est maladroit car ce script ne sécurise rien. Je voulais dire que, sauf réelle nécessité, il devrait être exclu des sites web publics. Il provoque des réactions très négatives chez les visiteurs.
- Certaines applications ne peuvent pas se contenter d'une solution aussi simple.
- Un avertissement "noscript" est bien sûr très utile.
- Ce petit script ne fait aucun appel au serveur : il s'agit d'une opération locale interne, utilisant le cache du navigateur du client.
- Le script résout le cas de Firefox : depuis la version 1.5 (fin 2005), son cache se comporte différemment. Voir, entre autres, la doc sur
http://developer.mozilla.org/fr/docs/Utilisation_du_cache_de_Firefox_1.5.
- Il n'y a aucun moyen de supprimer le bouton back du navigateur du client mais seulement de le neutraliser. Même en ouvrant une fenêtre sans menu, il reste la touche "retour" du clavier.
- Enfin, comme un bon exemple vaut mieux que de longues explications, j'invite les amateurs à une petite démo sur
http://users.skynet.be/mj/noback/page_1.html
Cordialement.
19 juil. 2008 à 14:12
"intéressant"
- location.replace peut parfois remplacer
- <noscript>au cas où</noscript>
peut "obliger" le javascript, le signaler...
- on peut gérer coté serveur
- on peut tester d'où on vient dans la
"page précédente"
- concevoir l'application "autrement"
et en fait... tout est là !
...
j'avais déjà vu ça, je ne suis pas le seul je pense ?
ça peut être utile dans certains contextes
( sans parler d'autre chose que d'éviter
les fausses manips d'un utilisateur )
en plus de l'aspect codage pas si simple.
bref... utile et intéressant :
la preuve : le nombre d'interventions.
Cordialement.
18 juil. 2008 à 10:10
18 juil. 2008 à 10:08
18 juil. 2008 à 03:54
Par contre, s'il y a une solution pour désactiver réellement le bouton précédent (et non un va et revient) je suis preneur (dans le cas d'une appli ajax cela peut être utile) car on voit bien que le navigateur repart vers B mais revient vers C aussi tôt ce qui est équivaut a 2 chargements au final.
Sinon c'est une bonne initiative!
Cordialement
17 juil. 2008 à 12:22
17 juil. 2008 à 11:45
Peut être que la vrais bonne technique c'est de combiner toutes ces méthodes selon la situation et du réel besoin que l'on a.
Enfin, je précise que ce genre de pratique n'est pas destiné a des pages web normales, c'est à réserver à un usage pour applications internes (publique restreins et avisé).
Merci pour la contribution ;-)
17 juil. 2008 à 11:42
je suis sur un site en page A je vais vers B puis vers une page sécurisée C, dans le cas d'un BACK, il n'y a pas de retour sur B mais uniquement sur A, sur C ou une autre page que B. Exemple de mise en oeuvre PHP sur le tuto de
http://www.phpfrance.com/tutoriaux/index.php/2006/09/27/45-comment-rediriger
En fait, on ne neutralise pas la touche BACK mais on joue sur la redirection.
17 juil. 2008 à 11:41
17 juil. 2008 à 11:30
17 juil. 2008 à 11:19
Et comme le dis si bien Martin72 rien de mieu est proposé à priori (testé je veux dire).
Concernant les header et l'expiration de la page ce serait pas mal de tester en effet mais à mon avis le résultat ne sera pas qu'on ne peut pas revenir en arrière et donc pas la même chose.
Concernant le fait de faire la même chose en PHP donc coté serveur il est évident que le site doit gérer le fait de revenir à la page précédente mais le php n'empèchera/limitera pas à mon avis l'utilisation du cache client et le click du bouton précédent qui est purement client.
Enfin je pense que l'idéal pour ce genre de script c'est pour un site entièrement fait en flash (comme deezer) tu fait une recherche dans google tu click sur l'url du site tu arrive sur le site tu commence à utiliser l'appli flash et sans faire exprès tu click sur précédent (ou tu appuis sur backspace) résultat tout se que tu as fait dans l'appli flash est perdu et tu te retrouve sur ta recherche google.
Avec l'utilisation de ce script cela évitera les erreur de manipulation.
17 juil. 2008 à 10:16
Dans le cadre d'une page nécessitant JS, pourquoi pas, mais jouer la carte sécurité unique sur une fonction JS j'ai des doutes. J'envisagerai une solution PHP par exemple.
16 juil. 2008 à 15:51
16 juil. 2008 à 15:27
16 juil. 2008 à 12:32
Sinon, je voulais quand même ajouter quand ton code marche normalement assez bien pour l'utilisateur non-averti.
16 juil. 2008 à 12:25
Plutôt que "interdire" et "obliger", il vaudrait mieux écrire "empêcher" et "convaincre".
Quelle est ta solution via headers ?
16 juil. 2008 à 11:24
Car si JavaScript est désactivé, ton visiteur accédera quand même à la page.
Disons que cela peut être une manière de le faire comprendre au visiteur, mais le serveur devra, lui, toujours gérer les "retours arrières" possibles du surfeur.
Mieux vaut faire expirer la page via les headers, par exemple.