hmm, as you already stated. the base64 encoded string is essentially the authorization. so having that, you do not need no user/password anymore.
also, in case we are going to support different auth schemes for http, we would have a problem if we fixed the saved auth to be base64 encoded. currently we simply assume that the server supports http://en.wikipedia.org/wiki/Basic_access_authentication and send it. this looks error prone, as there are other possible auth schemes. maybe they are not used widely for wms servers. not sure. Jukka, do you know? ok, i'd be willing to rework the UI to support user/pass textfields (pass obfuscated), but internally the auth stays plain text and will be saved as such into the state and project files. any try to obfuscate something into these files will be pointless as we are an _open_ source project. and decompiling java is also script kid level these days. at a later stage we might think about not saving passphrases (enabled via checkbox), but ask for them and cache them for each server session-wise. but that's just spitballing. ..ede On 16.12.2014 12:36, Rahkonen Jukka (Tike) wrote: > Hi, > > Some own experiences about small troubles because of how OJ is handling > username:password > > - When giving a presentation for audience on-screen or for someone in your > work room: URL-box shows username:password > - Credentials must be painted over from screen captures > - Workbench-state.xml stores URLs with credentials as plain text into > AddWMSQueryPlugin.CACHED_URL > - Project file (.jmp) does the same > > I am not an expert, but I suppose that a slightly better way to use Basic > auth would be to make OpenJUMP to write the http header "Authorizarion" > Authorization: Basic aHR0cHdhdGNoOmY= > http://www.httpwatch.com/httpgallery/authentication/ > > The base64 encoded string could be saved into workbench-state.xml and into OJ > project file even it is by no means safe if someone has an access to the > computer. Still it is hard to remember if only seen from the screen. > > User should still have a possibility to store the credentials so that they > are not prompted every time when adding a secured server to project. The same > authorization should be used for GetCapabilities and GetMaps and for > GetFeatureInfo, if we some day will have a support for that also. > > Other software has same kind of problems and if one knows what to do > username:password can be found for example from an open QGIS session. If not > otherwise then by unplugging the network cable it is often possible to > generate a revealing error message. It is better to remember that they are > called personal computers for a reason. > > -Jukka- > > ________________________________________ > edgar.soldin wrote: > > On 15.12.2014 22:45, Rahkonen Jukka (Tike) wrote: >> 1) OpenJUMP does not support very well authentication. All it can do is to >> add user:password before the base URL as >> https://user:password@base_url.<https://user:password@base_url./> > > we could obfuscate that behind an authentication prompt UI. not sure it is > worth the effort, as the user editing should be the user needing the data and > hence knowing the credentials to that wms server anyway. you might sway my > opinion here. > >> This is not the same URL that is advertised for GetMap because >> GetCapabilities document hopefully does not show the user name and password >> as plain text > > already fixed that locally, it reuses the credentials of the GetCap request > if the advertised GetMap url does not contain any, just for the weird case > they deliver creds. > the credentials are still shown in the text field though. > > additionally working on adding a possibility to modify wms url in > WMSQueryEditor later. > >> >> 2) The user:password in OpenJUMP is really tested only with https. Basic >> authentication withour https does not make much sense because credentials >> are too easy to capture from unsecured traffic. However, the server that >> Andrei is using does exactly use basic auth over plain http. > > right. http auth without encrypted transport layer is negligently insecure. > still, if the server is configured without SSL, who are we to judge and > prohibit access via plain HTTP. > > ..ede > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Jump-pilot-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Jump-pilot-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
