2017-06-04 16 views
0

私はカスタムポリシーを使用しています。 1.ユーザーは画面1に電子メール/パスワードを入力します。 2.画面1の検証が成功すると、ユーザーは画面2に送信されます。画面2では、ユーザーはコードを入力する必要があります彼らの電子メールに送信されます。 (サインアップ中にユーザーが既に電子メールを確認していることに注意してください)電子メールの検証をトリガーする

私は仕事に2時間疲れました。 ステップ1は電子メールの主張を出力します。

ステップ2では、電子メールクレームを入力します。

ステップ2では、電子メールが事前に入力された編集可能なテキストボックスが表示されます。コードは要求されません。しかし、電子メールが編集されると、コードが要求されます。

<TechnicalProfile Id="VerifyEmailAddress"> 
     <DisplayName>Local Account Signin</DisplayName> 
     <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> 
     <Metadata> 

     <Item Key="ContentDefinitionReferenceId">api.selfasserted</Item> 
     </Metadata> 
     <IncludeInSso>false</IncludeInSso> 
     <InputClaims> 
     <InputClaim ClaimTypeReferenceId="signInName" /> 
     </InputClaims> 
     <OutputClaims> 
     <OutputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="Verified.Email" Required="true"/> 
     <OutputClaim ClaimTypeReferenceId="objectId" /> 
     <OutputClaim ClaimTypeReferenceId="userPrincipalName" /> 
     <OutputClaim ClaimTypeReferenceId="authenticationSource" /> 
     </OutputClaims> 
     <ValidationTechnicalProfiles> 
     <ValidationTechnicalProfile ReferenceId="AAD-UserReadUsingEmailAddress" /> 
     </ValidationTechnicalProfiles> 

    </TechnicalProfile> 

答えて

0

うん、それは

私は基本的にそれを

<InputClaimsTransformations> 
    <InputClaimsTransformation ReferenceId="CopyClaimToreadOnly" /> 
</InputClaimsTransformations> 
<InputClaims> 
<InputClaim ClaimTypeReferenceId="myAlreadyPopulatedClaim" /> 
<InputClaim ClaimTypeReferenceId="myAlreadyPopulatedClaim-Readonly" /> 
</InputClaims> 
<OutputClaims> 
    <OutputClaim ClaimTypeReferenceId="myAlreadyPopulatedClaim-Readonly" 
PartnerClaimType="Verified.Email" /> 
</OutputClaims> 

あなたはまだあなたの主張を人口とすることを実現するために十分ありえないスマートな制御を行うことを主張変換を使用して、私のトラブルの多くを引き起こしました電子メールの入力と確認が同じページで実行されることを期待しています。分割したときに、この請求をコピーする必要があります。

希望があれば

関連する問題