We have URLs to a list of documents and we would like to check if a user has access to those documents. These documents require user login and password to access. Since the server requires NTLM authentication, we are using the JCIFS API to make a URL Connection to the document and checking the HTTP response code. If the response code is 401, then we are confirming that user does not have access. With this approach, does the document download all the content? Does the response time vary depending on the size of the document? Is there a better approach? Thanks in advance.
Config.setProperty("jcifs.smb.client.username", "<user_name>");
Config.setProperty("jcifs.smb.client.password", "<password>");
URL spURL = new URL("http://<host_name>/<folder_name>/<file_name>";
HttpURLConnection httpURLConnection = (HttpURLConnection) spURL
.openConnection();
NtlmHttpURLConnection ntlmHttpURLConnection = new NtlmHttpURLConnection(
httpURLConnection);
int resCode = ntlmHttpURLConnection.getResponseCode()
Thanks for your answers. I do not have a requirement to download the document, but my requirement is only to check if a user has access to a document or not. I am looking for a solution which is faster in terms of response and does not vary depending on the size of the document.
Hi, Thanks for your suggestions to set the request type as HEAD. There are lot of HTTP response codes that start with 2, 3, 4 and 5. Can you please explain me how I can interprese this? I am assuming the following intepretation; please correct me if I am wrong.
Any response code that starts with 2 means user has access to the document.
Any response code that starts with 3, I need to add further logic to make another request to actual URL?? Is there a code how this can be done automatically?
Any response code with 401 indicates user does not have access.
Any response code starting with 5 indicates, there is a problem with host server.
How about
httpURLConnection.setRequestMethod("HEAD");
?
When you download, there is not really any overhead. If you are not authorized, the server is not going to send the file back.
If you are posting large amount of data, you should use 100-Continue to make sure you are allowed to do so before proceeding. You can do it like this,
httpURLConnection.setRequestProperty("Expect", "100-continue");
Related
I'm building REST API, and when resource is created normally I return HTTP 201 Created along with Location header to specify where that resource is located. But from some reason http client is not redirecting.
I'm using Postman for this. Does anyone have idea on this problem?
In short, a Location header is not sufficient to trigger a client redirect. It must be used in conjunction with a 3xx HTTP status code.
References:
https://en.m.wikipedia.org/wiki/HTTP_location
Redirecting with a 201 created
This is one of those things where the expectation does not meet what actually happens, and the first thing people think is "well that doesn't work properly", as has been suggested in other comments.
The Location is just a random header, and clients, such as Postman or curl or anything else need to be instructed to follow them. Most won't do this by default, as that is an unreasonable default.
YouTube for example returns a body for some responses and a Location tag too. One example would be video uploads. They respond to your original meta-data for the video is sent with a POST, and they shove a Location URL which is the endpoint to upload the video too. If clients just randomly redirected to that you'd be having a bad time.
You can use Paw to make a "sequence", which I believe will let you take values from headers to reuse. This is also possible with Runscope Ghostinspector.
Simply souncloud servers responds with 502 Bad Gateway error on a /playlists call to API with client_id and user_id parameters. Issue regards a specific user, so maybe something it's messed up on server or on profile.. but how can I resolve?! There's no recovery procedure or similar to try things works again?
I ran into this issue myself and believe I have found the root cause. After trying the playlists query in browser & curl I was able to get the valid data response (JSON).
Turns out Soundcloud includes all the tracks information of each playlist! I have the max (500) tracks in some playlists so the response payload size must be the issue. It must also be why we get an occasional timeout response.
I will see what I can do about limiting the data size in the response and may try other libraries (I'm using soundcloud-ruby.)
I do not want my users to authenticate. But I do not anyone to steal my data. So my goal is to only serve the people who make a req from the front end of the app. How can I do this ?
Is there a built in function that I'm missing ? I know that there are session id generated, but not sure how to incorporate the session id to this situation.
Thanks
By using the term "front end" I would assume that you have a client requesting data in the form of JSON/XML or HTML templates. My first suggestion to get your answer is to be much more descriptive in your question. It is very hard to answer without knowing how your client is designed.
Assuming your client is written in html/js and run in a browser then I would suggest that you serve a static file (in the form of a .js file or a <script></script> tag inside an html file) that generates a token. You can pass this token back to your server for validation on every request for data. This means that only your app (front-end) can be the only thing that requests data from your api (back-end).
We have a login REST service:
POST /sessions
When the users password has expired the next thing that must happen is that the client application will present a change dialog window and then change the users password via:
PUT /users/_ID_/password
What is the best way to communicate this intent to the client? At first I wanted to have POST /sessions return See Other (303). But this causes a GET on /users/_ID_/password. I could return a Multiple Choices (300) response which the client does not do an automatic get on, or I could return an OK (200) and tag in the JSON session object returned.
Having a look at the HTTP status code definitions, I'm thinking the following is the best fit:
409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict and
resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem
There is a conflict with the current state of the session resource because the user needs to change their password before being able to create a session. You can return the url to the change password screen in this response so that the client knows where to go to fix the conflict.
At first I wanted to have POST /sessions return See Other (303).
This isn't correct. It would essentially be saying "Don't POST a session here, POST a session over there." You'd be relying on out-of-band information and hard-coded behaviour to recognise that this isn't the case and you should actually POST a new password there instead.
I could return a Multiple Choices (300) response which the client does not do an automatic get on
But you aren't offering multiple choices.
or I could return an OK (200) and tag in the JSON session object returned.
The POST wasn't successful, so you shouldn't respond with 200.
Are you really asking for the "correct REST response" or are you asking how to achieve a particular effect with HTTP? Because it seems you're looking for loopholes rather than the proper design.
If a request comes in and authorisation fails, then respond with 401 Unauthorized and a WWW-Authenticate header. Then use a custom authentication scheme that indicates the user needs to change their password.
In my application i need to implement verification if user has entered correct login and password or not. the login and the password are stored at the web server so i have to organize correct connection to the server. I'm an absolute beginner in everything about http requests and all that stuff. Actually i downloaded ASIHTTPRequest library and added it to my project just yesterday. My main problem is that i don't have an actual server by now (and i' m using just a conventional URL which later will be replaced with true server name but i want my code to be correct already)so i cannot test myself whether i'm doing things correctly or not.So my questions are:
1)What is the best way to organize verifying user's login and password? Should i use synchronous request or asynchronous? For all i know synchronous requests are rare in use cause they stop the application while the request is being performed but there's really nothing else needed to be done in this event so i'm a bit confused.What would you use?
2)I suppose verifying user's login and password by using http requests is pretty common task so there must be a general rule what kind of data the web server returns. I don't want to invent a wheel. should i use NSString returned by responseString to check if user's login and password match? What does server returns usually in such cases? How should my code look like? Something like
ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:someUrl];
[request startSynchronous];
NSString *response = [request responseString];
if ([response isEqualToString:#"login and password match"])
//user enters next screen
else
//user is notified about the error
or something else? What would you do?
3)This request is not only i need to implement. Later i'm going to connect to the same URL with a different request. So how does the server know what kind of request is currently being used?
I really need your advice. Great thanks in advance
I have tried to answer your question,
Q:1. Synchronous or Asynchronous request model for login?
-> As per apple's documentation
A synchronous load is built on top of the asynchronous loading code made
available by the class. The calling thread is blocked while the asynchronous
loading system performs the URL load on a thread spawned specifically for
this load request.
also,
NSURLConnection provides support for downloading the contents of an
NSURLRequest in a synchronous manner using the class method
sendSynchronousRequest:returningResponse:error:. Using this method is
not recommended, because it has severe limitations:
The client application blocks until the data has been completely
received, an error is encountered, or the request times out.
Minimal support is provided for requests that require authentication.
There is no means of modifying the default behavior of response
caching or accepting server redirects.
As you are unaware of server side implementation, which may involve:
1. Redirection and other mechanisms for fulfilling the request.
2. It may require some proxy authentication or other similar stuff.
Q:2. What does server returns usually in such cases?
In general, a web service is implemented at server-side which returns XML or JSON as repsonse which you have to parse and use.
example response may look like:
for XML:
<auth>
<statusCode>0</statusCode>
<statusMessage>Login Successful.</statusMessage>
</auth>
for JSON
{
"statusCode" = "0"
"statusMessage" = "Login Successful."
}
tags(for XML) and keys(for JSON) will depend upon you sever implementation.
3. How does the server know what kind of request is currently being used?
-> The URL which you will use for request will tell server, what you are looking for?
for example
http://www.example.com/mywebapp/getItem?id="1";
Thanks,
or
http://www.example.com/mywebapp/removeItem?id="1";
The bold path item represents services which you are calling.