Arborescence des pages

Connecteur appelé par le module cards. Il doit retourner la liste des cartes dématérialisées à afficher pour un utilisateur donné.

Paramètres d'appels

URL en méthode GET :

<host>/<uri>/<username>
  • host : adresse du serveur
  • uri : chemin éventuel vers le service
  • username : identifiant (login) de l'utilisateur pour lequel on souhaite les informations et les rôles, c'est à dire l'utilisateur qui se connecte. Le login sera celui retourné par le serveur CAS après authentification.

Pas de paramètres ou headers particuliers

Format de retour

Format attendu

{
	"lastname": String,
	"firstname": String,
	"birthdate": String,
	"gender": String,
	"affiliation": String,
	"photo": String,
	"ine": String,
	"errors": [String],
	"cards": {
		"studentCard": {
			"title": String,
            "subtitle": String,
            "endDate": Number,
            "idNumber": String,
            "csn": String,
            "qrCode": {
            	"type": String,
            	"value": String
            }
		},
		"euStudentCard": {
            "title": String,
            "subtitle": String,
            "endDate": Number,
            "idNumber": String, 
            "ecsn": Number,
            "euid": Number,
            "qrCode": {
            	"type": String,
            	"value": String
            }
        },
        "staffCard": {
            "title": String,
            "subtitle": String,
            "endDate": Number,
            "idNumber": String,
            "csn": String,
            "qrCode": {
            	"type": String,
            	"value": String
            }
        }
	}	
}

Les données à la racine seront les données communes à chaque carte :

  • lastname : nom de l’utilisateur

  • firstname : prénom de l’utilisateur

  • birthdate (nullable) : date de naissance de l’utilisateur

  • gender (nullable) : genre de l’utilisateur

  • affiliation : type d’utilisateur (student | staff)

  • photo : photo de l’utilisateur encodée en base64

  • ine (nullable) : code INE de l’utilisateur (dans le cas où l’utilisateur est un étudiant)

Toutes les cartes de l’utilisateur seront placées sous un attribut “cards”. Libre à l'établissement de fournir les données qu’il souhaite pour chaque carte. Il suffit simplement que le type de carte soit défini pour savoir quel SVG utiliser derrière, et qu’on retrouve les variables déclarées dans le SVG correspondant.
NB : pour chaque objet de type “card”, on retrouvera un attribut qrCode qui peut être nullable si l'établissement ne souhaite pas associer de QRCode à la carte affichée. Pour le moment on s’en tiendra à seulement 2 types de QRCode simple qui sont text et url. Si un établissement veut mettre en place d’autres types (SMS, mailto, vcard…), il devra adapter le code.

  • type : type d’action au scan du QRCode (text|url)

  • value : la valeur du QRCode à générer (texte pour un QR de type text ou une url pour un QR de type url)

Enfin, à chaque type de carte devra correspondre un template SVG. Par exemple : Pour l’Université de Lorraine, nous avons identifié 3 types de carte différents (soit 3 templates SVG) : studentCard, euStudentCard et staffCard.

Limite

On ne peut pas ajouter de données a afficher dans le SVG.

Cas d'erreur

Codes erreurs

Liste des codes erreurs actuels concernant l’API des cartes dématérialisées :

  • NO_PHOTO : l’utilisateur ne peut pas disposer d’une carte car il n’a pas fourni de photo (à la scolarité de la formation pour un étudiant / à la RH pour les personnels)

  • NO_ACTIVE_CARD : l’utilisateur ne dispose pas d’une carte active à l’Université

  • UNPAID_FEES : l'étudiant (ou doctorant) ne voit pas sa carte dématérialisée s’afficher car il n’a pas encore payé les droits d’inscription pour l’année en cours

Ces codes erreurs sont actuellement retournés avec un code HTTP 200 car il ne s’agit pas d’une erreur au sens propre de l’API mais plutôt d’une indication à l’utilisateur qu’il ne peut pas disposer d’une carte dématérialisée dans l’application mobile.

Autres erreurs

user_not_found (code 404) : L’utilisateur dont le login est passé en paramètre lors de l’appel n’a pas pu être trouvé dans le SI de l’Université

Exemple :

{
    "error": "user_not_found_in_ldap",
    "error_description": "L'utilisateur avec pour uidNumber or login 'bidule' n'a pas pu être trouvé dans le LDAP ou est sursitaire"
}


L’application catche donc 2 types d’erreur :

  • celles dont le code HTTP n’est pas 200

  • celles pour lesquelles l’attribut errors est renseigné dans la réponse

Exemple

{
    "lastname": "Didier",
    "firstname": "Céline",
    "gender": null,
    "affiliation": "staff",
    "ine": null,
    "errors": [],
    "photo": "data:image/jpeg;base64,/9j/4pleindecaracteres"
	"cards": {
        "staffCard": {
            "title": "Carte Professionnelle",
            "subtitle": null,
            "endDate": "2024",
            "idNumber": "UL0000123456",
            "csn": "0A0A0A0A0A0A",
            "qrCode": {
                "type": "text",
                "value": "00000@ul"
            }
        }
    }
}



  • Aucune étiquette