marklogic-community
login is form-encoded instead of restful
spec: "POST body, form encoded, username, password"
This needs to be a rest endpoint.
My preference is to use Spring login services as-is, out of the box. I cast about for some other login payload and mechanism -- can you point me to a resource about this?
Here's the passport module for username/password auth, which looks just about the same as what Spring provides. http://passportjs.org/guide/username-password/
Passport is indeed what we may use in Node. And I'm not hung up on whether you use Spring or something else, but the other issue #87 has a link to how to do this in Spring. It seems like we're getting some non-RESTful behavior out of it, maybe there's a setting.
OK I've found a good resource for the expected behavior in RESTful login and how to get spring to do it http://www.baeldung.com/2011/10/31/securing-a-restful-web-service-with-spring-security-3-1-part-3/ How blocked are you/your team on this - I'd like to figure out when to jump on this issue.
You know, it sounds as though you'd really just prefer digest authentication. Or rather, it sounds as though digest authentication does what you're expecting from a RESTful auth.
I reviewed the requirements and there's really nothing requiring a login form like I've presented... should I just rework the app and func spec to use digest authentication?
Pretty blocked. Auth is kind of the top priority.
We definitely don't want any forms or HTML-based error messages to come from the server. Pure https statii and JSON.
The issues where I tried to start this conversation is https://github.com/marklogic/samplestack-internal/issues/36 , because login is all bound up in CSRF and session creation.
Before you implement anything, let's make sure that I've been clear enough about expectations and requirements from a security standpoint. We should have an architecture that is consistent with both CORS and CSRF even if we don't address either of them -- we can't tell customers to build an app in a way that is incompatible with them.
By "pretty blocked" I meant, of the various things about which I've been creating issues, I'd say this is the tops. Practically speaking, we can adjust our next couple of days if it takes a couple of days to do this.
When you say digest I say, I want to work with a REST server over http. When wearing my browser hat, I don't care how you implement security I just want a session object on a REST server using a RESTful endpoint (either having one created for me in response to a POST, or by me creating one with a PUT. I want to speak JSON to rest endpoints and nothing else.
In order to have a browser session, I want a GET which establishes the session and gives me a CSRF token.
And I want CORS preflighting.
CORS and CSRF can wait. I think we need the GET session and PUT credentials to happen very soon.
When I put invalid credentials, I expect a 400 or 401.
When I have a session and try to do something I can't, I expect a 403. When I have no session or an unauthenticated session and I try to do something that requires a session, I expect a 401.
GET /v1/session:
- no body
- returns a session object plus any cookies I need for the session. By EA3, it should also have a CSRF token. No parameters required. If I already have a session cookie don't create a new session.
PUT /v1/session:
- body: { "username": "joe", "password": "jopa" }
- respond with 200 and the user profile, including but maybe not limited to the roles that the user has in LDAP.
- response with 400 or 401 if auth fails
We can also consider making a CSRF exception for login such that the app is allowed to POST a session without getting an empty on from the server.
To me, it's enough for now that one or the other get in place.
Hi Stu,.
I can get back on this now. The example you cite above, which looks as though it's what you want, just uses http basic authentication. This would certainly be supported by any browser and any client app; alternatives would be digest or openid. Anything beyond that is going to be moving into a custom implementation as far as current Spring development is considered.
I suggest that for right now, I get ready a change that uses http basic or digest, so I can unblock your integration. I think I'd even like to verify auth myself from the browser layer so we don't have to bat it around. Does that sound like a good approach for the immediate term?
I think this is resolved now in PR, at least as far as EA-2 goes. We can revisit for more RESTful functionality as part of EA-3/node implementation.
Can someone add a related task in EA3 for us to revisit? makes sense to close this one if resolved for EA2.
Just to document where we landed (correct me if I'm wrong): use form-encoded for EA2 on the Java stack. That's what Spring expects and we are prioritizing middle tier experience. To the extent that it drives customization in the second (Node) stack and depending on level of customization in browser, may revisit in EA3.
FWIW, I would say that cleanliness of the reference architecture is the reason to revisit in ea3.
Moving to 8.0-1 as I'm not sure it was resolved yet. Would like to triage what the open question is here before GA.
Or Sorry Charles did i mess up your system - perhaps you moved to N/A to show as a non-feature task?
Product Staff consensus/directive is that we mark things as N/A when we have no specific plan for a change to occur in a specific release. So N/A means "we don't yet know when or if this will ever land" but we are maintaining an assignment to a person who is responsible for moving the change forward or otherwise resolving it. We shouldn't say 9.0 unless we're saying that we've decided not to do something in 8.0-2, for instance. If it might get into 8.0-2 or might slip to 10.0-1 then we should leave it as N/A.
Now that the authn/authz mechanism is mostly custom code anyhow, I bet it wouldn't be much more to get to this ideal place.
FWIW, removing the current workaround in the browser is a no-brainer once the server is able to do a JSON-based login.