[asterisk-dev] [Code Review] 2987: ARI: Don't leak information about implementation details

[David Lee]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2987/#review10147
-----------------------------------------------------------



branches/12/include/asterisk/stasis.h
<https://reviewboard.asterisk.org/r/2987/#comment19413>

    I'm a bit torn here.
    
    In principle, I like the idea of passing in the sanitizer so that different consumers can sanitize JSON to their own needs.
    
    But the fact that you have to pass around the sanitizer object everywhere, given that we only have one implementation, feels a bit weighty to the API.
    
    I don't have a good suggestion for a solution. Just complaining out loud...



branches/12/main/rtp_engine.c
<https://reviewboard.asterisk.org/r/2987/#comment19414>

    Just a guess, but I think you'd want to drop the RTCP report completely if the associated channel was filtered out by the sanitizer.



branches/12/main/stasis_bridges.c
<https://reviewboard.asterisk.org/r/2987/#comment19416>

    Would I be right in assuming that if either bridge was filtered out, then ast_json_pack() returns NULL, effectively filtering out the message?
    
    If so, I would rather be explicitly return NULL when either snapshot is NULL. The underlying Jansson json_pack() behavior is undocumented, and could easily change in a future release.
    
    If not, then you'll end up with messages that effectively have missing fields, and it would be better to filter them out entirely.
    
    Either way, this (and several other to_json methods below) need an explicit check to filter them out if one of their fields were null.


- David Lee


On Nov. 6, 2013, 1:46 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2987/
> -----------------------------------------------------------
> 
> (Updated Nov. 6, 2013, 1:46 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22744
>     https://issues.asterisk.org/jira/browse/ASTERISK-22744
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This change prevents channels used as implementation details from leaking out to ARI. It does this by preventing creation of JSON blobs of channel snapshots created from those channels and sanitizing JSON blobs of bridge snapshots as they are created. This introduces a framework for excluding information from output targeted at Stasis applications on a consumer-by-consumer basis using channel sanitization callbacks which could be extended to bridges or endpoints if necessary.
> 
> This results in NULL inputs to ast_json_pack calls which generate unhelpful error messages, so that has been dealt with as well.
> 
> This also corrects a bug I noticed while investigating the issue where BridgeCreated events would not be created.
> 
> 
> Diffs
> -----
> 
>   branches/12/res/stasis/app.c 402347 
>   branches/12/res/res_stasis.c 402347 
>   branches/12/res/ari/resource_endpoints.c 402347 
>   branches/12/res/ari/resource_channels.c 402347 
>   branches/12/res/ari/resource_bridges.c 402347 
>   branches/12/main/stasis_message.c 402347 
>   branches/12/main/stasis_endpoints.c 402347 
>   branches/12/main/stasis_channels.c 402347 
>   branches/12/main/stasis_bridges.c 402347 
>   branches/12/main/rtp_engine.c 402347 
>   branches/12/main/json.c 402347 
>   branches/12/include/asterisk/stasis_endpoints.h 402347 
>   branches/12/include/asterisk/stasis_channels.h 402347 
>   branches/12/include/asterisk/stasis_bridges.h 402347 
>   branches/12/include/asterisk/stasis_app.h 402347 
>   branches/12/include/asterisk/stasis.h 402347 
> 
> Diff: https://reviewboard.asterisk.org/r/2987/diff/
> 
> 
> Testing
> -------
> 
> Manual testing with bridges and channels.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131107/534b8c97/attachment.html>