[asterisk-gui] interface to list of providers

Thu Aug 28 15:53:51 CDT 2008

I suppose so. The problem is that is defeating the _very_ reason we 
implemented this, so that
we can make updates to the providers list in real time.

-Brandon

Klaus Ruebsam wrote:
> How about a
>
> ------------------
> Feature request:
>
> Additional Field somewhere underneath 
>
> Options -> General Preferences
>
> By default pointing to the JS-file at DIGIUM. But everyone may be free to
> wget that JS-file manually, place it somewhere on his own web-server and
> change the above entry field to point to that own webserver. IMHO the
> corresponding value (URL) should be stored somewhere within
> /etc/asterisk/http.conf
>
> Action required:
> 1. Add additional variable within http.conf somewehere underneath the
> [general] section, let´s call it
>
> providersinfo = https://gui-dl.digium.com/providers.js 
>
> No change within Asterisk itself required as variable gets only read by the
> GUI
>
>
> 2. Wihtin the above mentioned menue-section of the GUI an additional
> inputfield (keep it long enough) plus a button, named "Default" or "DIGIUM"
> that would overwrite the field with
> "https://gui-dl.digium.com/providers.js". The JS-file as of the release date
> of the GUI version used, may additionally be saved (during installation of
> the GUI) somewhere underneath http://myasterisk:8088/asterisk/static/config/
> making an additional and initial wget of the file no longer necesary.
> ------------------
>
> How about that one? That should make all of us happy, shouldn´t it? And
> implementation shouldn´t be that difficult.
>
>
> Best regards,
>
> Klaus
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: asterisk-gui-bounces at lists.digium.com
> [mailto:asterisk-gui-bounces at lists.digium.com] Im Auftrag von bkruse
> Gesendet: Donnerstag, 28. August 2008 21:00
> An: Asterisk GUI project discussion
> Betreff: Re: [asterisk-gui] interface to list of providers
>
> The whole idea behind this is that we _can_ push updates of Service
> Providers.
>
> We will test this internally, but it is better than the alternative (having
> a provider that does not work when they are certified to work)
>
> Not to mention this will rarely happen.
>
> As far as the remote thing, it is an equiv of a "wget", what about when you
> go to sites and you see "request pages from analytics.google.com", or
> requesting advertising javascript files. If you are worried about javascript
> security, and your overall security, there are much better, and more
> vulnerable, places to start at.
>
> -bk
>
> Pari Nannapaneni wrote:
>   
>>> Not to get into semantics:
>>>
>>> The obvious fact is that the local page gets information from a 
>>> remote page. For the purpose of usage statistics, maybe even a simple 
>>> data file or an image would do the same.
>>>     
>>>       
>> Sure, i think having discussions about any security/privacy concerns are
>>     
> always a good thing.
>   
>>   
>>     
>>> This still does not address the original issue.
>>> Also note that the URL should be HTTPS or use some other equivalent 
>>> messure to protect from DNS spoofs and such.
>>>     
>>>       
>> It is a HTTPS URL with a valid SSL cert.
>>
>> thanks,
>> -Pari
>>
>>
>> ----- Original Message -----
>> From: "Tzafrir Cohen" <tzafrir.cohen at xorcom.com>
>> To: asterisk-gui at lists.digium.com
>> Sent: Thursday, August 28, 2008 1:11:28 PM GMT -06:00 US/Canada 
>> Central
>> Subject: Re: [asterisk-gui] interface to list of providers
>>
>> On Thu, Aug 28, 2008 at 08:40:45AM -0500, Pari Nannapaneni wrote:
>>   
>>     
>>> Hi Tzafrir,
>>>
>>>     
>>>       
>>>> 1. Privacy implications
>>>> Every time I use this configuration page, it reports home. 
>>>>       
>>>>         
>>> "reports home" would be kind of a strong word.
>>>
>>> I would agree with what you said,
>>>  [A] if there is 'a banner-Ad script served from a 3rd party website" 
>>> in the gui  [B] if the gui had some third party scripts like "google
>>>       
> analytics"
>   
>>>  [C] if the script is a mashup 
>>>      I don't think this really qualifies as a 'mashup', as there is NOWAY
>>>       
> the script
>   
>>>      can read any of your cookies set by other websites. 
>>>      - Unless you are embedding the gui in someother website via an
>>>       
> iframe.
>   
>>>  [D] if the script served is obfuscated using some javascript 
>>> obfuscator  [E] OR if the script makes any XMLhttprequest to Digium or
>>>       
> some other website.
>   
>>> Its straight forward javascript file, like the rest of the scripts in the
>>>       
> GUI.
>   
>>>     
>>>       
>> Not to get into semantics:
>>
>> The obvious fact is that the local page gets information from a remote 
>> page. For the purpose of usage statistics, maybe even a simple data 
>> file or an image would do the same.
>>
>> A quick grep before posting this message showed me that this was the 
>> only case of such a "remote" content.
>>
>> It also means that part of the functionality is not available if the 
>> system has no internet access (or is behind a very strict firewall).
>>
>>   
>>     
>>> The only difference being that it is loaded from a different URL, and 
>>> the GUI tells the same to the user and loads the script only after 
>>> taking a confirmation from the user.
>>>
>>> Yes, the webserver's log file will contain a bunch of IP addresses 
>>> which requested the js file, but thats like saying "i won't use VOIP
>>>       
> because the person on the other end might know my IP address".
>   
>>>     
>>>       
>>>> 2. Untested code
>>>> This feature means I run a whole bunch of javascript code from a 
>>>> remote site. Later on some modifications in that page may break my 
>>>> page and I would not even be aware of that.
>>>>       
>>>>         
>>> We will see what we can do about this.
>>>
>>> Right now, the providers file is on a different svn repository.
>>> I will see if there is a way to somehow move the providers script 
>>> file into the gui repository, so that any changes made to the file 
>>> would be public.
>>>     
>>>       
>> This still does not address the original issue.
>> Also note that the URL should be HTTPS or use some other equivalent 
>> messure to protect from DNS spoofs and such.
>>
>>   
>>     
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-gui mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-gui
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-gui mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-gui
>   