Lorawan-stack: Réutilisation des EUI des passerelles supprimées

Créé le 7 août 2019 · 7Commentaires · Source: TheThingsNetwork/lorawan-stack

Résumé

Lorsque vous supprimez une passerelle, puis en ajoutez une nouvelle avec le même EUI, si cela échoue car il se plaint que la passerelle existe déjà.

Étapes à suivre pour reproduire

Supprimer une passerelle existante
Ajoutez-le à l'aide de la CLI ou
Ajoutez-le à l'aide de l'API

Que voyez-vous maintenant ?

{
    "code": 6,
    "message": "error:pkg/identityserver/store:already_exists (entity already exists)",
    "details": [
        {
            "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
            "namespace": "pkg/identityserver/store",
            "name": "already_exists",
            "message_format": "entity already exists",
            "attributes": {
                "field": "gateway_eui",
                "value": "'3135313749005303'"
            },
            "correlation_id": "c0dc6bb73d714702bd8d0be57e83f369"
        }
    ]
}

Que veux-tu voir à la place ?

Créer avec succès la nouvelle passerelle

Environnement

amazon linux utilisant TTN CLI et Postman utilisant API Call

Comment proposez-vous de mettre cela en œuvre ?

Lorsque l'utilisateur essaie d'insérer une passerelle supprimée, mettez à jour l'indicateur supprimé sur false

Pouvez-vous le faire vous-même et soumettre une demande d'extraction ?

...

identity server in progress

Source

adamsondelacruz

Tous les 7 commentaires

Lié à https://github.com/TheThingsNetwork/lorawan-stack/issues/1121

htdvisser le 7 août 2019

J'ai un peu mis à jour ce problème pour avoir une portée légèrement différente de # 1121, que nous pouvons faire plus sur la restauration des entités supprimées en général (au lieu des seules applications).

Dans le numéro actuel, concentrons-nous davantage sur l'ajout de nouvelles passerelles avec le même EUI qu'une passerelle supprimée.

htdvisser le 7 août 2019

Lié à https://github.com/TheThingsNetwork/lorawan-stack/issues/604 (libération des identifiants/EUI)

htdvisser le 7 août 2019

@htdvisser même avoir https://github.com/TheThingsNetwork/lorawan-stack/issues/1703 (maintenant dans Next Up) ne couvre pas entièrement le cas d'utilisation courant de pouvoir créer une passerelle avec un EUI qui a déjà été utilisé . Faire une boucle dans un administrateur pour purger une entité n'est pas une expérience utilisateur agréable, et purger une entité est plus destructeur que de simplement libérer l'EUI.

Afaik, nous n'avons pas de problèmes de sécurité avec la libération de l'EUI lors de la suppression de la passerelle. C'est déjà facultatif. Cela rendrait, évidemment, la récupération partielle, c'est-à-dire que l'EUI a disparu, mais je pense que c'est acceptable et correspond également à la façon dont les EUI de l'appareil sont libérés immédiatement lors de la suppression.

Pouvons-nous résoudre ce problème en publiant simplement l'EUI lors de la suppression de la passerelle ? Si non, pourquoi pas ?

johanstokking le 5 janv. 2020

👍1

Oui, nous pourrions mettre à jour le champ Gateway EUI à nil/NULL lors de la suppression. Cela devrait être aussi simple que d'ajouter un

// AfterDelete releases the EUI of a Gateway after it is deleted.
func (gtw *Gateway) AfterDelete(db *gorm.DB) error {
    return db.Unscoped().Model(gtw).UpdateColumn("gateway_eui", nil).Error
}

en pkg/identityserver/store/hooks.go .

htdvisser le 9 janv. 2020

@bafonins pouvez-vous ramasser ça?

johanstokking le 9 janv. 2020

👍1

@adamsondelacruz veuillez rouvrir si https://github.com/TheThingsNetwork/lorawan-stack/pull/1843 ne résout pas le problème.