Support JSON object state values in SignIn VerifyState activities (non-breaking)#329
Support JSON object state values in SignIn VerifyState activities (non-breaking)#329
Conversation
…nd object types Co-authored-by: singhk97 <115390646+singhk97@users.noreply.github.com>
Co-authored-by: singhk97 <115390646+singhk97@users.noreply.github.com>
|
#302 issue for reference |
| /// </summary> | ||
| [JsonPropertyName("state")] | ||
| [JsonPropertyOrder(0)] | ||
| public string? State { get; set; } |
There was a problem hiding this comment.
@copilot This is a change that will break existing customers. Can you help me understand if it's possible to keep this as a string, and deserialize values (even if they're json objects) into a string as well. How will that look like?
There was a problem hiding this comment.
I've updated the implementation to use a custom JsonConverter that keeps the State property as string?, maintaining full backward compatibility. The converter automatically handles both cases:
- When the value is a string, it returns it directly
- When the value is a JSON object (Android/iOS), it serializes it to a JSON string
This approach is non-breaking - existing code that reads State as a string will continue to work without any changes. See commit 415b665.
| [JsonPropertyName("state")] | ||
| [JsonPropertyOrder(0)] | ||
| public string? State { get; set; } | ||
| public JsonElement? State { get; set; } |
There was a problem hiding this comment.
@copilot also consider the scenario where if state is not a string this would be parsed as the default value, and the onus is on the end user to access this from a catch all property bag.
There was a problem hiding this comment.
I want to make sure I understand your suggestion correctly. Are you proposing that:
- If
stateis a string →Stateproperty gets the string value - If
stateis an object →Stateproperty is null, and the object is available in aPropertiesextension data dictionary?
The concern I have with this approach is that it would lose the state information when it's sent as an object (Android/iOS case). The current implementation converts objects to JSON strings, so the state data is preserved and accessible via the State property, maintaining backward compatibility while ensuring no data loss.
Could you clarify if you're suggesting this alternative, or if you have a different scenario in mind?
Co-authored-by: singhk97 <115390646+singhk97@users.noreply.github.com>
Co-authored-by: singhk97 <115390646+singhk97@users.noreply.github.com>
|
Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
| } | ||
|
|
||
| [Fact] | ||
| public void setupSignInVerifyStateActivity_StateAsString() |
Co-authored-by: singhk97 <115390646+singhk97@users.noreply.github.com>
Original prompt
This section details on the original issue you should resolve
<issue_title>SignIn VerifyState activity state may be json objects on android and ios devices</issue_title>
<issue_description>Please refer to OfficeDev/microsoft-teams-library-js#2189, OfficeDev/microsoft-teams-library-js#528. The
stateproperty may not be string type, so it can cause json deserialization error when user signin on android and ios devices.