OpenConcerto

Bonjour à tous,
Je développe actuellement un site web ainsi que des applications faisant intervenir certaines données comptables, en d'autre termes j'utilise et modifie la base de données d'openconcerto moi même pour automatiser les choses.

Mais le problème est en fait extrêmement simple, tellement que je me demande si à force de chercher je n'aurai pas vu le gros bouton bien en vue fait pour cela ^^ Il s'agit tout simplement de ne pas utiliser le mot de passe par défaut de connexion à la base de données (qui par defaut est login : openconcerto, mdp pareil). N'ayant pas trouvé dans la documentation comment changer cela, j'ai jeté un coup d'oeil sur les codes sources et em suisvite aperçu qu'il faudrait simplement spécifier les paramètres server.login et server.password. Voire ce lien ligne 271, c'est assez clair. Mais sans doute n'ais-je pas vu une subtilité, car pas moyen de le faire utiliser ces identifiants, il me ressort toujours role "opencocerto" doesn't exists, preuve qu'il n'utilise pas le login spécifié. Mon fichier de config :

server.login=my_db_login
server.password=*******
server.ip=ip_server.com\:49526
server.driver=postgresql
customer=Gestion_Default

Et je suis certain qu'il utilise ce fichier de config car il se connecte sur le bon port.
Je pourrais bien compiler depuis le svn en changeant le mot de passe et login par defaut ... mais bon il ya forcément moyen de le faire "proprement"pourtant ...

Merci d'avance,
Dominqiue B.

Bonsoir,

pure folie que d'ouvrir à tout vent le port de PostgreSQL... et encore plus de le publier sur un forum...

Regardez plutôt du côté des paramètres server.wan.* , OpenConcerto se chargera de faire un tunnel à travers SSH...

Cordialement,

Bonjour Dominique0796,

ces paramètres (user et password) représente un compte de connexion ssh, utilisé pour le tunneling, ce n'est pas le compte d'accès BDD, malheureusement ce dernier est codé en dure dans le source, pour le changer il faut le faire a ce niveau et recompiler le code, ou bien customize ton projet (source) afin que ce compte soit paramétrable.

pour le ssh il ne résout en rien l'exposition du port BDD, voici un sénario:

Le user et pwd BDD étant connu: (inchangé pour ceux qui travail sur les releases seulment)
le fichier main.properties et stocké en claire, tu récupère les paramètres.
tu ouvre un tunnel ssh (ex: PTTY)
tu lance un client BDD, et tu te connect vers l'adresse local:port local du tunnel en utilisant le compte BDD par defaut.

Bonjour,

Vu que seuls les utilisateurs ont accès au tunnel SSH, cette solution est totalement sécurisée (vis à vis de toute connexion externe).

Si un pirate a accès à votre main.properties c'est que vous avez un gros problème de sécurité en amont

Cordialement,

Bonjour,
la vous supposez que tous les utilisateurs sont approuvés, et ne peuvent en aucun cas porté préjudice au système par un acte malintentionné.
Dans ce cas pourquoi chaque utilisateur dispose de son propre mot de passe? pour quoi votre système "OC" gère t-il plusieurs privilèges?

Par mon scénario je voulais vous montrer qu'un utilisateur, peut accéder à la B.D.D toute entière et en faire tout ce qu'il veut, en court-circuitant vos règles de gestion des privilèges.

sans parler des risque de piratage.

la ont parle des principe fondateurs de la sécurité des S.I, a mon avis cette limite n'est pas propre à "OC", mais plutôt au modèle d'architecture Client-Serveur, seule les architectures centralisées (app web), ntiers ou ws peuvent outrepassé cette limite.

Cordialement,
Nabil.

Bonjour,

Vous avez raison, OpenConcerto est fait pour fonctionner dans un système fermé, celui de l'entreprise.
Dans ce contexte, seuls les utilisateurs légitimes peuvent "pirater" le système si l'administrateur permet l’exécution des outils nécessaires.
Cela nécessite d'avoir les connaissances nécessaires pour faire un tunnel ssh, se connecter à une base de données, etc...

Les utilisateurs disposent de mot de passe pour être identifiées, on ne peut pas faire beaucoup plus en système client-serveur. Nous développons déjà depuis plusieurs mois le système n-tiers qui sera la solution que vous attendez... après libre à vous de vous battre avec les utilisateurs pour qu'ils ne partagent pas leurs mots de passes "au cas ou"

Cordialement,

Je vous souhaite toute la réussite, et bon courage

Bonjour,

Autant je suis une bille, un abruti total en compta ... autant mon boulot est dans la securité des SI.

Qu'est ce qu'un système fermé de nos jours ?
Qui peut se targuer de travailler sur un poste totalement déconnecté d'internet .. à l'air du Cloud, ou la prochaine version de Windows sera la dernière en tant que telle que la plus part des systèmes vont adopté le type "rolling release" et que les AppStore, Windows Store, apt-get, yum nécessite d'etre connecté ce qui inclus d'etre constamment connecté.
Croyez vous que vous allez a chaque fois couper votre connection WiFi ou débrancher votre cable ou mettre en place la regle firewall qui va bien ?

Je rappelle que le principal vecteur de piratage est un element interne.

D'un point de vue externe il s'uffit de rebondir et de pratiquer de l'injection SQL pour pouvoir repartir à l'age de pierre.

Parmis tous le BEABA, ne jamais jamais jamais garder les parametres (port, compte, mot de passe, ...) par defaut et utiliser des mots de passe à forte complexité !

Du coup on se retrouve avec nom de l'application = nom du compte = mot de passe !

Vous n'imaginez pas le nombre de site qui fonctionne avec les valeurs par defaut.

Le nerf de la guerre de nos jour est bien la donnée et quoi de mieux qu'une base comptable/cliente pour collecter de la donnée.

Le secteur financier estime les pertes chaque année pour raison de piratage a 465 Mds (evaporation de données, utilisation frauduleuse ...)

Cela n'engage que moi mais je pense que de pouvoir changer le compte et le mot de passe d'acces par quelque chose d'unique serait un plus.

Cordialement

Bonjour,

Comment souhaitez vous fournir les login & mot de passe de la base de donnée à l'application ?
Fichier sur le disque dur ?

Cordialement,

A vrai dire, il n'y a pas tellement de solution, parce que même avec un login/mdp spécifique pour la bdd, il ne serait pas possible d'y appliquer les contraintes logicielles (droits spécifiques à chaque module). Seule option, disposer d'un module "serveur", lequel gère la communication avec la bdd, et une connexion de type API entre le logiciel et le serveur.

Cela dit, il reste vrai que de pouvoir spécifier les login et mdp pour chaque instance serait mieux, ne serait-ce que pour faire cohabiter plusieurs instances pour des utilisateurs totalement distincts (différentes sociétés dans des bdd distinctes sur le même SGBD).