I have some private pages on my site. Those pages are accessible only for logged in users. Now, if user is not logged and he tries to visit one of those private pages he gets 301 redirect to an index pages. That's not good for SEO and not user-friendly.
What is a good practice to sort it out? Is a good idea to show a sign in form with 401 http status together?
HTTP 301 means that the requested resource was "Moved Permanently"
HTTP 401 means that the user is "Unauthorized" to access this resource.
So yes, presenting a login page with status code 401 is the way to go.
That's exactly what this status code was thought for.
Related
I have a situation, when I should to send a POST request to authenticate user, if it's succeed then server set a cookie and then we can get a protected page:
First request by Postman:
Second request (after first):
I need to implement it on web page. As I understand now, it's possible only via frames. How to do it? First request should be sent automatically after opening a page, so, user should open the page and see a protected page.
Cookie Authentication is you are trying to achieve?, here is are some links which will help to you with that.
https://dzone.com/articles/cookie-authentication-with-aspnet-core-20
I have a webpage /example with a form that has action="/submit". submit will process the data sent to the server, and return a 302 redirect back to /example.
I would like to have (the second) /example display some sort of response to the user based on what the user submits to /submit, such as an indication of success or failure.
Sending a 302 redirect doesn't seem to have any way to tell the client to send any additional message to /example, so the server is unable to determine if it should indicate success or failure when fetching /example for the client.
I could append the success or failure message to the 302 redirect url, i.e. redirect to /example?message=Succeeded, but that url will stay on the user's address bar as long as he continues to browse my /example page, which isn't very nice.
I could change the form to have action="/example", but I have multiple forms on the /example page, so I would need to use hidden <input> elements or other means to distinguish the requests submitted by the user to /example. This seems to be more of a hack than a proper solution.
What is the usual way this can be accomplished?
I am trying to build a front end application which will an input text box.
When a user enters an URL in the text field(ex www.google.com, wwww.facebook.com, www.linked.com, etc..), the web app should tell the user whether if the provided address has a re-direction?
Can it be done from ajax?
You can send a GET request to the URL and see what it returns.
Every HTTP response will come with a status code.
You can see the full list of HTTP status codes here: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
A 301 means the URL has a permanent redirect and a 302 means there is a temporary redirect.
I have a REST api written in node which uses HATEOAS. The user is required to have an account before they can access the bulk of it.
They register an account with login details, then login to obtain an access token, and then use that token in order to access any endpoints that aren't register or login.
Issuing a get to the root responds with a directory with available actions.
Q: What is the correct response from register, to tell the client what it can do next (i.e. login)?
register technically creates a new resource on the server so a 201 CREATED and a Location header would seem appopriate. However the login reference isn't the location of the newly created resource.
Should I return 201 Created with a Location pointing to the newly created user (e.g. /myaccount or /users/{id} and then include a login link in the response body?
{
_links: {
self: { href: "what goes here?" },
x:login: { href: "/login" }
}
}
Do I not tell the client at all, and require them to do a get on the application root in order to fetch a list of available endpoints. This should include login anyway. Assuming the client had to do that in the first place to get the register link it should already have login.
Expecting the client already to already have the login link feels uncomfortable as it relies on an assumption of the client's prior activity.
Requiring the client to issue another request to the root directory after registering seems mean, inefficient and unnecessary. If the client has just created a resource it seems only fair that the server should respond with what it can do with it next.
I like to have my api's act no differently than a webpage. If you want the UX of your application to be the user is taken to login after they register, then 302 them from a successful register to the login resource. And upon successful login, 302 to them to the appropriate destination (IE, if they tried to access something with no token, then take them to login, with a destination of the original requested resource). That's and important part to your #3. Having a link off the root that leads to login, but you need to protect all the other links such that they indicate (and link to) a login being required to access the resource. The client app should expect to get this login required response at any time as tokens can (and do) expire at any time.
Following on this, it might make sense to do the JWT as a cookie instead of as an Authorization Header, it would make it a bit easier for the client (they just have to setup a cookie jar)..if the client is say a native mobile app that maintains a single connection setup. If it's server to server, then auth header makes sense. I'd go about supporting both to cover both scenarios.
Continuing on the idea of thinking of the api as a web site. Why have them login after registration at all? Why not have the registering of an account end up with the login token being sent? they just set their user/pass, why make them enter it again? I realize with some more exotic architectures the register service can not perform the login action (perhaps it doesn't have the private key to sign the token), but if it is possible i'd consider it.
If you really want to stick to the 201 header (which is fine, just make sure the docs of your register relationship indicate that), then option 2 is the closest in my opinion. A location header to the URL of the account just created a 201 is pretty standard for creating a user. But, i'd not return what you've supposed there. You're kind of returning a account-created resource (the thing with the login link), but do you really need this custom resource? If you want to give some messaging back to the client (like "Account Created") in that resource then absolutely yes, but you could also just give them back the root resource.
tl;dr; Decide what you want your UX to be and then make your API implement your UX.
Greetings, everyone:
Firstly, sorry that my Flow description is long winded, but I think it might help with describing the problem.
Background:
Building asp.C# shopping app that is using a hosted payment page to process payments (using posting of data to a hosted payment page). SSL certificate is signed and installed.
Flow:
Prelim) (HTTPS) Users authenticate using asp Login control
1) Users add items to cart.
2) (HTTPS)Users go to checkout page.
3) Users finalize their order, then click pay now after agreeing to T&C.
4) Server gets cart data (from MSSQL2005) and sets a transaction cookie (expiry set to 20 mins).
5) (HTTPS) Server Response.Redirects to an html page (in the same folder as the login protected pages).
6) Html page reads transaction cookie data and generates form fields.
7) (HTTPS) Html page posts data to hosted payment page (php).
8) User enters payment info and clicks pay now.
9) (HTTPS) hosted payment page posts info back to a .aspx page that checks if payment OK.
10a) If payment !OK, redirects to a declined page.
10b) (HTTPS) If payment OK, sets a verification cookie (expiry set to 20 mins). Then redirects to another html page.
11) Html page reads cookie data and generates form fields.
12) (HTTPS) Html page posts data to hosted verification page (php).
13) Verification page verifies (of course), if transaction ok.
14) (HTTPS) verification page posts data to a .aspx page that checks if verification OK.
15) If verification OK, process orders and do receipt stuff.
Issue:
This control flow was tested on an unsigned dev environment. SSL was being enforced, if needed on the unsigned SSL certificate. So we'd get prompts that certificate may be bad, but the control flow worked seamlessly.
However, now live with a signed SSL certificate, going from step 5 to 6, we are encountering a situation where some users (not duplicated every time, but verified that it does occur) when they click pay now and are redirected to the html page, they are forced back to the ~/login.aspx page (as if they were logged out).
Things to note:
a) The session did not time out.
b) The browsers have cookies and javascript enabled.
c) I can process the entire flow seamlessly on the same machine with other accounts, and occasionally, the same account.
So, basically, I'm stumped... Is this a viewstate error? A login control bug that won't let me redirect to an html page because it is now using a real SSL? Anyone have any experience with this kind of deal? I'm at a loss for solutions at this point.
Any help would be greatly appreciated. Kind Regards,
jra
It's just that if you let your authentication cookie out on plain HTTP at any time during the flow, you lose the security. Secure cookies are meant to protect against this, and I'm just wondering if there might be a change in configuration in that area. – Bruno Sep 10 at 14:36
Seems this problem has been resolved. Thanks again for your assistance, Bruno!