I'm wondering if there is a way to change a user's password through API?
Apparently, this was possible by using SetUserPreferences (https://www.mediawiki.org/wiki/API:Edit_-_Set_user_preferences), but this is no longer supported. And the API Options feature (https://www.mediawiki.org/wiki/API:Options) doesn't seem to have the option to change passwords.
Is there a way that allows me to do such a thing?
You can do it via the (not very well documented) changeauthenticationdata API. The API is fairly generic as the authentication system might change from wiki to wiki and does not necessarily involve passwords.
Related
I want to make a website about sharing locations. But I couldn't find how to get user's location. This will be free application so I don't want to pay Google or anything else. I will use the python 3.x so there is no js.If it's free I will be very happy.
Functionality such as geolocation requires the use of JavaScript. The feature you are looking for is the Geolocation JavaScript API.
Python cannot do in the browser what JavaScript can do. They are used for completely different things in the context of websites. Python can be used on the backend, but to add most dynamic functionality on the frontend, you need JavaScript.
The only way to figure out a user's location, without directly asking them, is by their IP.
I found python-geoip through a quick Google search, which seems to offer what you're looking for.
Other than that, you could use HTML forms to actually ask the user their location, which doesn't require any JavaScript, just HTML, and then process that information on the backend.
Does anyone know why Box.com make it so hard to generate an authorization code programmatically? I wrote some code to do this through screen-scraping, and then recently this broke because (as far as I can tell) one HTTP request parameter changed from [root_readwrite] to root_readwrite. I was able to fix it reasonably quickly (thank you Fiddler), but why make developers go to this trouble?
Judging by the number of questions on this topic, many developers need to do this, presumably for good reason, and I don't think it can be prevented, so why not just embrace it?
Thanks for listening, Martin
The issue with doing OAuth programmatically is that it would effectively defeat the point of OAuth. Users are supposed to be presented with the Box login page so that they never have to give their username and password directly to your app. This allows users to see what permissions your app has over their account (the scope) and also allows them to revoke your app at any time.
Doing login programmatically means that at some point your app knows the user's password. This requires that the user trusts you to not do anything malicious, which usually isn't feasible unless you're a well-trusted name. The user also has to trust that you handle their credentials correctly and won't use them in an insecure way.
Box wants to encourage developers to do authentication the correct and secure way, and therefore isn't likely to support doing OAuth programmatically. You should really try to perform login the supported way by going through the Box login page.
Hoping someone can remedy my naivety when it comes to calling a simple URL to an application (which returns XML) using NTLMv2.
I have read pretty much every question and page there is but I am left with one overriding curiosity. I am using the HTTPClient at present (although this can be changed) along with the latest JDK (at the time of writing).
Here is an example page which appears to call the JCIFS library:
http://hc.apache.org/httpcomponents-client-ga/ntlm.html
All looks good, albeit confusing, but this highlights the question that many of the examples I have seen raises - the issue of supplying NTCredentials.
To me the whole point of NTLM is so that I do not have to supply credentials. The target aplication is set up to use NTLM so surely the user credntials of the currently logged in user should be used? Why should I be supplying any credentials myself?
Apologies if I am missing something obvious here. I just need the most basic for of NTLM SSO possible using Java. I don't care what version of what, I am able to use the latest of anything.
Holding out hope! Thanks for reading.
Unfortunately, there's way to do single sign-on in a pure Java environment.
NTLM isn't a solution to single sign-on directly. NTLM is a challenge/response authentication mechanism and it requires the NTLM hash of the user's password. Windows machines are able to provide single sign-on using NTLM because the NTLM hash is persisted. They are then able to compute the response to a challenge based on the persisted hash.
Without access to that hash (and, to my knowledge, you can't simply request it) you need to compute it yourself. And that requires having the user's password.
Similarly, you can do single sign-on with a Kerberos ticket using SPNEGO authentication (if the remote system is setup to support it, of course) but Java unfortunately reimplemented Kerberos instead of using the system Kerberos libraries. So even if you were already logged in to the domain, you'd need to go get another Kerberos ticket for Java. And that means typing your password in again.
The only realistic way to avoid typing in a password to authenticate is to call the native methods. On Windows, this is SSPI, which will provide you the ability to respond to an NTLM or SPNEGO challenge. On non-Windows platforms, this is handled by the very similar GSSAPI and provides the ability to respond to SPNEGO (Kerberos).
I was searching for a solution of the following problem, so far without success: I'm planning a RESTful web service, where certain actions (e.g. DELETE) should require a special authentication.
The idea is, that users have a normal username/password login (session based or Basic Auth, doesn't really matter here) using which they can access the service. Some actions require an additional authentication in form of a PIN code or maybe even a one-time password. Including the extra piece of authentication into the login process is not possible (and would miss the point of the whole exercise).
I thought about special headers (something like X-OTP-Authetication) but that would make it impossible to access the service via a standard HTML page (no means to include a custom header into a link).
Another option was HTTP query parameters, but that seems to be discouraged, especially for DELETE.
Any ideas how to tackle this problem?
From REST Web Service Security with jQuery Front-End
If you haven't already, I'd recommend some reading on OAuth 1.0 and 2.0. They are both used by some of the bigger API, such as Facebook, Netflix, Twitter, and more. 2.0 is still in draft, but that hasn't stopped anyone from implementing it and using it as it is more simple for a client to use. It sounds like you want something more complicated and more secure, so you might want to focus on 1.0.
I always found Netflix's Authentication Overview to be a good explanation for clients.
How can I get the MAC address (or something unique for each pc -at least standard user knowledge level-) from client side with js,flash,java or etc. using a crossbrowser method?
You probably know when we are coding a poll we should use cookies to prevent multiple voting.
I couldn't find a crossbrowser javascript method (without MS IEs activex). Javascript, java applet or flash files will be welcome.
Thank you
Caglar
There are no standard Javascript APIs for getting a mac address.
It is possible to get this information using a Java applet, but it would need to be signed and have a policy file in order to access hardware info, and it wouldn't really be transparent to the user. See Getting MAC address on a web page using a Java applet
If you just need to track a client, the most reliable thing you can do is use a combination of APIs available to Javascript to create a persistent cookie. It's possible to create a very resilient cookie using a combination of standard HTTP cookies, session storage APIs, caching tricks, and plugins. Evercookie is a great example: http://samy.pl/evercookie/
You can't do that with JavaScript. Otherwise any one can lure you to visit their website will be able to peek your MAC address, and that would be a security issue. You can only do it through plug-ins. And the browser will have to prompt user to explicitly allow that plugin first.