Yes, so if someone does not want to use this free DIGIUM service, he has to make sure that he keeps his data (JS-file) up to date by himself, baring in mind NOT to blame DIGIUM for possible home-made problems. To prevent unwanted blaming there could be a kind of "warning" on the "System Status" page reminding that the providers-data is NOT pulled from DIGIUM, but from somewhere else with a direct link to the Options->General Preferences page. That should make it really "dummy-proof" :-)
Best regards, Klaus -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von bkruse Gesendet: Donnerstag, 28. August 2008 22:54 An: Asterisk GUI project discussion Betreff: Re: [asterisk-gui] interface to list of providers 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> >> To: [email protected] >> 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 > _______________________________________________ --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
