La solution proposée consiste à ajouter le permalink aux attributs de session, mais je ne sais pas laquelle ? Vous est-il possible de m’éclairer sur où récupérer la variable session dont il est question ci-dessous ?
OK on regardera ça mais dans le cadre de la 6.3+ car on ne backportera plus rien (hors correctifs de sécurité critiques) sur la 6.2 d’ici sa fin de maintenance
J’ai testé avec un deep link de liste (<base URL>?l=DemoSupplier) et de formulaire (<base URL>?f=DemoSupplier%3B2) et un permalink (<base URL>/ui/l/suppliers-bim) et je ne vois pas de pb avec ce customAuth minimal:
package com.simplicite.commons.Application;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class PlatformHooks extends com.simplicite.util.engine.PlatformHooksInterface {
@Override
public String customAuth(HttpServletRequest request, HttpServletResponse response) throws Exception {
return "designer";
}
}
Je pense donc que votre customAuth fait des choses plus subtiles qui font perdre les liens profonds.
Ou alors peut être simplement que les permalinks sont vides pour les records que vous testez (ceux-ci se calculent au save du record). Faites une vérification en base du contenu de la colonne row_permalink de la table de votre objet car c’est sur cette base que le permalink est généré/recherché (et transformé en deep link)
@Francois,il manque peut être une action “Recalculer tous les permalinks” car ça peut être pénible de devoir forcer un save sur tous les records (NB: ça peut se faire en update en masse) pour remplir la colonne row_permalink
Merci de ta réponse, je suis en train de retester pour te donner plus d’élements.
En revanche je n’ai pas row_permalink mais obj_permalink, c’est de cela qu’on parle ?
Je suis aussi intéressée par plus d’infos sur
c’est sur cette base que le permalink est généré/recherché (et transformé en deep link)
D’accord je pensais qu’il s’agissait d’une colonne dans la table m_object.
J’ai vérifié et on a bien cette colonne dans la table de notre objet métier, renseignée correctement.
Et concernant l’idée derrière le customAuth, il s’agit de connecter avec un User par défaut les personnes qui reviennent en erreur de la connexion OKTA :
OKTA error → customError → customAuth → user par défaut
Peux tu tester que tu as le bon comportement avec le customAuth basique que j’ai utilisé dans mes tests = return "designer"; (ATTENTION de bien retourner designer pour pouvoir conserver l’accès designer).
C’est juste pour vérifier qu’il n’y a pas une subtilité dans votre cas ailleurs que dans la logique de votre customAuth.
Et, pour info, quand on utilise un permalink, techniquement (et de manière transparente pour l’utilisateur) il est converti en deeplink.
Ma question c’est juste de savoir si, avec un customAuth basique (= return "designer";), les permalinks et les deelinks fonctionnent (lors de mes tests c’est bien le cas).
L’objectif c’est de savoir si le pb est dans ce que fait votre customAuth particulier ou si c’est un pb plus général.
