Enabling the attribute callback stores identity email in application state at sign-in
Source references: 5The Skill recommends receiving identity-provider attributes in a sign-in callback and demonstrates writing email into persistent application state by principal. Collection occurs through the sign-in callback rather than only when a user actively submits profile data.
The application then holds personally identifying email data; later backups, administrative interfaces, state exports, or application vulnerabilities could broaden its exposure.
This risk applies when the app supplies a non-null callback to `MixinAuthorization`: verified name, email, and SSO attributes are then delivered to the app once per sign-in. The example stores email by principal in an application `emails` map and exposes a caller-only getter. Users can ask the author to document retention, deletion, and purpose, or require the second argument to remain `null` and collect only necessary attributes. The shown source does not send email to an external service.
`MixinAuthorization` can capture the user's verified Internet Identity attributes (name and email) at sign-in. Pass a callback as the second argument instead of `null`; it runs once per sign-in, after the attribute bundle has been verified.Show 4 other places
Store them in your own state and expose a getter to read them back: let emails : Map.Map<Principal, Text>; include MixinAuthorization( accessControlState, ?(func(caller : Principal, attrs : { name : ?Text; email : ?Text; sso : ?Text }) { switch (attrs.email) { case (?email) { emails.add(caller, email) }; case null {}; }; }), include MixinAuthorization( accessControlState, ?(func(caller : Principal, attrs : { name : ?Text; email : ?Text; sso : ?Text }) { switch (attrs.email) { case (?email) { emails.add(caller, email) }; case null {}; }; }), ); public query ({ caller }) func getCallerEmail() : async ?Text { emails.get(caller); };};