Recherche avancée

Médias (91)

Autres articles (48)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • MediaSPIP version 0.1 Beta

    16 avril 2011, par

    MediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

Sur d’autres sites (5397)

  • Merge branch 'master' of https://github.com/lipka/piecon

    2 août 2012, par lipka
    Merge branch 'master' of https://github.com/lipka/piecon

  • fix wrong https value when server value has capital letters. Also is usually a better idea to check for on that for off

    18 juillet 2013
    fix wrong https value when server value has capital letters. Also is usually a better idea to check for on that for off

  • Anomalie #4097 : bug HTTPS dans la fonction url_de_base() sur certains serveurs mal configurés

    3 avril 2018, par cedric -

    C’est casse gueule car url_de_base() utilise le nom de domaine de l’URL courante et pas celui de la meta adresse site, et rien ne garantit que le certificat soit aussi valide pour ce domaine.

    Typiquement si le site est accessible en http par un nom de domaine générique on rend cet accès inopérant dans ce cas.
    Je pense que si on veut aller par là, il faut vérifier que le nom de domaine est le même que celui de la meta adresse site, et je ne sais pas si malgré tout c’est une bonne idée car avec ce patch on perd la distinction http/https à partir du moment où on a mis https dans l’adresse du site.

    J’aurais tendance à penser qu’en cas de serveur mal configuré, cas exotique, le hack dans le mes_options.php est la meilleure option

    $_SERVER[’HTTPS’] = "on" ;
$_SERVER[’SERVER_PORT’]=’443’ ;

    car il est fait en connaissance de cause (le serveur est mal configuré, ne pas attendre un en-tête https) alors que le patch dans le core va influer le comportement de tout le monde, y compris sur les serveurs bien configurés

Navigation