Detaillierte Erläuterung der stillen Anmeldung beim WeChat-Applet und der Aufrechterhaltung des benutzerdefinierten Anmeldestatus

1. Hintergrund

In einem Miniprogramm ist OpenID die Benutzerkennung für ein Miniprogramm/öffentliches Konto. Entwickler können den Benutzer anhand dieser Kennung identifizieren, genau wie mit Ihrem Personalausweis.

2. Was ist ein stiller Login?

In gängigen Anwendungen melden sich Benutzer über eine Formularauthentifizierung an, um ein Benutzersystem einzurichten. Diese gängige Anmeldemethode erfolgt im Allgemeinen über das Anmeldeseitenformular, was für Benutzer erkennbar ist.

Da das Miniprogramm auf WeChat basiert, können wir die von WeChat offiziell bereitgestellten API-Funktionen verwenden, um die Benutzeridentität (OpenID) unbewusst abzurufen und schnell ein Benutzersystem innerhalb des Miniprogramms einzurichten. Dies ist für den Benutzer nicht wahrnehmbar, sodass das Programm den automatischen Anmeldevorgang abschließt.

2.1 Ablauf des Login-Vorgangs

Das folgende Bild stammt vom offiziellen WeChat

Das Applet ruft wx.login() auf, um den Code abzurufen und auf den Server hochzuladen

Exportiere asynchrone Funktion doLogin() {
 wenn (istLogin) false zurückgibt
 isLogin = true
 entferneCache('token')
 const { code } = warte auf wxp.login()
 const Daten = warte auf Anmeldung({ Code })
 setCache('token', Daten.Daten.token)
 isLogin = false
 returniere wahr
}

Der Server erhält den Code und ruft die Schnittstelle auth.code2Session auf, um ihn gegen OpenID auszutauschen.
const getOpenid = asynchrone Funktion (App-ID, Geheimnis, Code) {
    const resData = warte auf axios.get('https://api.weixin.qq.com/sns/jscode2session?appid=' + appid + '&secret=' + secret + '&js_code=' + code + '&grant_type=authorization_code');
    gibt resData.data zurück;
}

Fassen Sie den Prozess zusammen:

• Das Applet ruft wx.login() auf, um den Code abzurufen und auf den Server hochzuladen
• Der Server verwendet den Code und ruft die WeChat auth.code2Session-Schnittstelle auf, um sie gegen OpenID auszutauschen
• Der Backend-Server generiert ein benutzerdefiniertes Token basierend auf der OpenID, gibt es an das Frontend zurück und speichert es. Die nachfolgende Geschäftslogik verwendet das Token, um den Benutzer zu identifizieren.

3. So behalten Sie einen benutzerdefinierten Anmeldestatus bei

Schauen wir uns den offiziellen Ansatz an:

wx.checkSession({
  Erfolg () {
    //session_key ist nicht abgelaufen und ist während dieses Lebenszyklus gültig},
  scheitern () {
    //session_key ist abgelaufen, Sie müssen den Anmeldevorgang erneut ausführen wx.login() //Erneut anmelden}
})

Aus der Abbildung können wir erkennen, dass es die checkSession-Schnittstelle von WeChat ist, die den Anmeldestatus tatsächlich bestimmt. Daher rufen Sie jedes Mal, wenn Sie prüfen, ob der Benutzeranmeldestatus gültig ist, zuerst eine checkSession-Schnittstelle auf. Wenn der Sitzungsschlüssel ungültig ist, leiten Sie den Anmeldevorgang ein.

4. Gesamtprozess der stillen Anmeldung

4.1 Anmeldung in app.onLaunch eingeleitet

Da für die meisten API-Aufrufe eine Token-Verifizierung erforderlich ist, empfiehlt es sich, die stille Anmeldung beim Start des Miniprogramms in der periodischen Funktion app.onLaunch einzuleiten.

4.2 Das Verarbeitungs-Applet unterstützt keine asynchrone Blockierung

Da die Lebenszyklusfunktionen auf Seiten- und Komponentenebene keine asynchrone Blockierung im Startvorgang des Miniprogramms unterstützen, kann eine Situation auftreten, in der die Lebenszyklusfunktion auf Seitenebene bereits eine Anforderung an den Server initiiert hat, bevor das in app.onLaunch initiierte wx.login erfolgreich ist. Da die meisten unserer Schnittstellendesigns eine Überprüfung erfordern, war die Anmeldung zu diesem Zeitpunkt nicht erfolgreich und das Token wurde nicht korrekt zurückgegeben. Daher meldet die vom Lebenszyklus auf Seitenebene initiierte Datenerfassungsschnittstelle definitiv einen Fehler (z. B. wird 401 zurückgegeben).

4.2.1 Grobe Lösung

Verwenden der Rückruffunktion

//app.js
dies.globalData.wxp.showLoading({
        Titel: „Anmelden …“
      });
      warte auf Anmeldung();
      this.globalData.hasLogin = true;
      wenn (this.checkLoginReadyCallback) {
        this.checkLoginReadyCallback();
      }
      this.globalData.wxp.hideLoading();
      
Im Lebenszyklus der Seite async onLoad() {
    wenn (app.globalData.hasLogin) {
    //Wenn Sie bereits angemeldet sind, holen Sie sich die Daten direkt this.getUserInfo();
      dies.getEvent();
    } anders {
    //Definieren Sie die Rückruffunktion, wenn Sie nicht angemeldet sind, und rufen Sie sie auf, nachdem sich app.js erfolgreich angemeldet hat. app.checkLoginReadyCallback = async () => {
        dies.getUserInfo();
        dies.getEvent();
      };
    }
  },

Vorteile: Einfach und grob

Nachteile: Schlechte Codestruktur; wenn mehrere Seiten Startseiten sind, müssen Callback-Funktionen für mehrere Seiten definiert werden (vorausgesetzt, das Miniprogramm im onShare-Modus wird verwendet)

4.2.2 Der elegante Weg

Mithilfe der Bibliothek fly.js wird ein Sperrmechanismus für Anfragen implementiert. Ablauf: Der Login wird in app.js eingeleitet, außerdem wird eine Anfrage auf der Seite initiiert. Stellen Sie im Anforderungs-Interceptor fest, ob sich die angeforderte Schnittstelle auf der Whitelist befindet (Schnittstelle, für die keine Token-Verifizierung erforderlich ist) und ob die Schnittstelle und das Token vorhanden sind. Wenn beide falsch sind, sperren Sie die aktuelle Anforderung in der Anforderungswarteschlange und führen Sie den Anmeldevorgang aus. Nachdem Sie gewartet haben, bis der Anmeldevorgang erfolgreich war, entsperren Sie die Anforderungswarteschlange und fahren Sie mit der Initiierung von Anforderungsaufgaben auf Seitenebene fort. Nachfolgend sehen Sie den Code im Anforderungs-Interceptor:

//Abfangverarbeitung fly.interceptors.request.use(async (request) => {
	// Alle Anfragen ohne Token und nicht in der Whitelist werden gesperrt, wenn (
		!getCache('token') &&
		!whiteList.some((Element) => request.url.startsWith(Element))
	) {
		fliegen.sperren()
		//Entsperren nach erfolgreichem Login
		warte auf doLogin()
		fly.unlock() //Nach dem Entsperren werden weiterhin Aufgaben in der Anforderungswarteschlange initiiert }

	wenn (getCache('token') && !fly.config.headers['Authorization']) {
		request.headers['Autorisierung'] = getCache('Token')
	}
	request.headers['Inhaltstyp'] = 'Anwendung/x-www-form-urlencoded'

	Rücksendeantrag
})

Natürlich können auch benutzerdefinierte Anmeldezustände ablaufen. Wir können Fehler im Antwort-Interceptor zur Verarbeitung erfassen: Wenn ein 401-Token-Ablaufcode erkannt wird, müssen alle Anforderungen hinter der Anforderungswarteschlange gesperrt werden, um zu verhindern, dass mehrere 401-Anmeldezustände ablaufen. Dann muss die Anmeldung initiiert und nach erfolgreicher Anmeldung entsperrt werden, um nachfolgende Ausführungen der Anforderungswarteschlange auszulösen und die Schnittstelle erneut auszuführen, die vom Server aufgrund des Token-Ablaufs abgelehnt wurde. Andernfalls schlägt die Anforderung fehl (da die stille Anmeldung von Benutzern nicht wahrgenommen wird, wird das plötzliche Ablaufen der Authentifizierungsinformationen bei Benutzern ein besonders seltsames Gefühl hervorrufen, sodass dieser Anforderungsvorgang erneut ausgeführt werden muss, anstatt dass der Benutzer erneut klickt oder ihn durch andere Aktionen initiiert):

// Antwortabfangen fly.interceptors.response.use(
	(Antwort) => {
		//Gibt nur das Datenfeld des Anforderungsergebnisses zurück return response.data
	},
	async (Fehler) => {
		wenn (err.status === 401) {
			//Nach 401 werden alle nachfolgenden Anfragen gesperrt, um erneuten 401 zu verhindern
			fliegen.sperren()
			entferneCache('token')
			//Entsperren nach erfolgreichem Login
			const isLoginSuccess = warte auf doLogin()
			wenn (istLoginErfolgreich) {
				fliegen.entsperren()
			}
                        // Führe die Schnittstelle, die vom Server aufgrund des Token-Ablaufs abgelehnt wurde, erneut aus. return fly.request(err.request)
		}
	}
)

Da die Anforderungen gleichzeitig erfolgen können, wird die Funktion doLogin leicht geändert, um zu verhindern, dass die Anmeldung mehrmals ausgeführt wird (obwohl sie nicht elegant geschrieben ist, sind meine Fähigkeiten begrenzt, also klären Sie mich bitte auf):

Exportiere asynchrone Funktion doLogin() {
        //Wenn Sie sich anmelden, führen Sie es nicht aus, wenn (isLogin) false zurückgibt.
	isLogin = true
        //Ändere den Status auf „Angemeldet“, melde dich trotzdem mehrmals an removeCache('token')
	const { code } = warte auf wxp.login()
	const Daten = warte auf Anmeldung({ Code })
	setCache('token', Daten.Daten.token)
	isLogin = false
	returniere wahr
}

4.3 Gesamtablaufdiagramm

5. Abschließende Gedanken

Leser, die auf die Details achten, werden feststellen, dass in der API-Anforderung keine maximale Anzahl von Anforderungen festgelegt ist (das WeChat Mini-Programm unterstützt die gleichzeitige Initiierung von bis zu fünf APIs), die ergänzt werden muss. Insgesamt ist der Autor der Ansicht, dass bei den Implementierungsmethoden noch Verbesserungsbedarf besteht. Die Fähigkeiten des Autors sind begrenzt, daher lernt und diskutiert er gleichzeitig!

Dies ist das Ende dieses Artikels über die stille Anmeldung und die Beibehaltung des benutzerdefinierten Anmeldestatus des WeChat Mini-Programms. Weitere relevante Inhalte zur stillen Anmeldung des WeChat Mini-Programms finden Sie in früheren Artikeln von 123WORDPRESS.COM oder in den verwandten Artikeln unten. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!