I'm fairly new to clojure, and I'm trying to add an authentication system to a compujure app and for that I'm using cemerick.friend.
All the routes are working fine, but I'm never able to login, even when using a dummy in memory database (if you can call it that).
The problem, I believe, is on the cemerick.friend.credentials/bcrypt-credential-fn, which is never validating my credentials.
Here's a gist with the relevant code: https://gist.github.com/zamith/5940965
Any help on how to solve this problem would be nice.
Thanks.
You want to use workflows/interactive-form where currently you specify workflows/interactive-login-redirect.
The latter function's purpose is to serve as the default :login-failure-handler. What it does is perform the redirect after a failed login attempt; it certainly makes no attempt to log a user in.
You also need to remove the (resp/redirect "/signup") from the body of the friend/authenticated form in your "/dashboard" route, as it's unconditionally redirecting logged in users to the signup page. (That the redirect happens is in fact proof of the user being authenticated, since otherwise the body of friend/authenticated would not be evaluated and there's nothing else in the code which could cause a redirect to "/signup".)
With these two changes, the app works for me.
Related
one question, maybe it's a bit longer, but i really hope someone can help me 🙏
I've been reading the docs but simply can't figure it out.
Is there a way i can create a signup feature where user creates an account (only simple one, email and pw) , and that account data is saved somewhere in a json file
And then the user can login via post method by typing his credntials.
And if credentials are correct (out of any other credentials there are in that particular json file) he gets a random jwt.
I mean i know i need to set up the rules if email and pw match any user and pw from the json file
Thanks!
Mockoon offers mostly stateless and independant endpoints mocking. Which means, there is currently no easy way to "code" it for such advanced use cases.
You can simulate a POST /signup and POST /login call, make sure the request looks OK by using Mockoon's rules, but they will not be linked and the credentials will not be persisted.
A system of CRUD endpoints is currently under development but it will allow for JSON manipulation only, not the kind of behavior you describe which is also very close to a production application.
I authorized the group of a user to the cockpit-application. I gave the group full access to the Process Definition and Process Instance authorizations. (so pretty much as described in the documentation)
When I try to log the user in, I see the Welcome screen and in the application overview the option to navigate to the cockpit-application.
However, when I click this, I get the Login screen again.
For a fraction of a second I see the cockpit application, but then it immidiatly redirects to the login page. When I try to log in again, it keeps redirecting me to this login screen.
I configured another group to use the Tasklist application and that is working as expected.
I tried to give the authorization on user-level instead of group-level but the same problems occurs.
(n.b.: I am using the Spring-Camunda-Starter for this application.)
I found the problem, I accidentally removed one of the authorizations the system automatically creates when the user is created. I think I might have removed this, as I thought it was not necessary.
It is in the User Authorizations, every user has an authorization from it's own user to that user. When I added this, it fixed the problem.
I found the solution when another user logged in and had no problems. And the found this to be the only difference between the two accounts.
Hopefully this will help someone in the future!
We have a site that uses a "one-time" login process for password resets which are not initiated by the user themselves. (for instance, a password reset that is initiated by an admin or another employee) A URL is sent to the user via email which can then be used to reset their password. The URL can only be visited one time. (there's more to this for security-sake but I'll keep it simple) Recently, some users have complained that when they visit the link, it has already expired. The end result is that they can't reset their passwords using this feature. We discovered that the users in question have a spam filter or "link checker" in their environment that they do not have access to. This device visits the one-time link before the user is able to, to make sure its safe.
I'm trying to solve this issue and was wondering if there's a way I can detect these type of devices on the web server when the request is made? When the spam filter visits the link, is there something in the http request that would stand apart from a regular browser? Maybe they all use a specific custom HTTP header? Or maybe there's a regex I could use on the user agent? I haven't been able to catch one of these yet, so I'm not sure what the request looks like coming from a spam filter.
Anyone know of a way to detect spam filters of any vendor by looking at the http requests? I know it's a long shot but maybe they all use a specific header for reasons such as this?
I got approval to modify the design to remove the one-time aspect of the URL. This solves the issue and saves me the headache. Thanks for the suggestion, #PeeHaa
I've looked hard into this article about OAuth Authorization Server with OWIN/Katana: http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
The article does tell us how to set up a basic Auth server but seems to omit a lot of information and code. I'm particularly interested in the implicit grant flow. They did provide the login page and the "permissions" page, but I'm confused:
Where is the code that decides whether the authenticated user has granted the client? This can't be done "behind the scenes" because we NEVER told any middleware "component" the path "/OAuth/Authorize".
Where is the code that actually redirects the user back to the client's website, along with the auto-generated access_token and other values?
I'm suspecting that there is a proper way to "construct" the ClaimsIdentity object (particularly the scope claims) before passing it to authentication.SignIn(claimsIdentity) in /OAuth/Authorize, so that it would automatically redirect the user back to the client with access and refresh tokens.
The MVC Actions of /OAuth/Authorize and /Accounts/Login seem to always return View() even after successful authentication and granting, thus never forwards the user back to the client's website. This seems like I would have to manually determine when to return Redirect(Request.QueryString["RedirectUrl"]);, and figure out the encrypted values to pass along with it. This doesn't seem like I should be generating the exact response.
What did I overlook?
As #(LittleBobby Tables) said your questions are very broad.
Based on how you asked the question you actual understand the topics but not the how?
I suggest you look at the full source code at
http://code.msdn.microsoft.com/OWIN-OAuth-20-Authorization-ba2b8783/file/114932/1/AuthorizationServer.zip
Your answers are either present or will lead you in the right direction
I'm allowing users to login to my site with either OpenID, Twitter OAuth or FBConnect. If the user attempts to go to a page that requires them to be logged in, after that user logs in I want to send them BACK to that page. Is there an easy way to accomplish this with all of these or should I simply just write the redirect page to a cookie and upon a successful login send them to that page? I'm using Django so if there are any nice tips or tricks involving that specifically that would be great.
Thanks for the input in advance!
You could thread that parameter (the page they were at) through as a parameter to your return_to. As noted in the spec:
Note: The return_to URL MAY be used as a mechanism for the Relying Party to attach context about the authentication request to the authentication response. This document does not define a mechanism by which the RP can ensure that query parameters are not modified by outside parties; such a mechanism can be defined by the RP itself.
For example:
def sendOpenIDCheck(...):
# after getting an AuthRequest from Consumer.begin
return_to = oidutil.appendArgs(return_to,
{'destination_url': that_place_they_tried_to_go})
return redirect(auth_request.redirectURL, realm, return_to))
def handleReturnTo(request):
# after doing Consumer.complete and receiving a SuccessResponse:
return redirect(request.GET['destination_url'])
If there's some other state you need to track (like POST data), or you have an extraordinarily long URL that you can't fit in as a query parameter, or you need to have the destination_url tampered with by the user, you store that information server-side, send the key as a query parameter instead of a URL, and look it up when they get back.
Not very different from storing it in the session, unless the user's got several simultaneous tabs in one session that run in to this, and then having it in the query helps.
Sadly OAuth and OpenID aren't really aware of your app states (while OAuth WRAP can be). So you have to take the following assumption:
The user will complete the sign-in WITHOUT switching tabs/windows or doing other requests on your site.
Then you can do the following:
Once you detect the access of a protected site, store the full query in the session. This won't work at all if it's a POST request, you have to prepare for this problem (show them a warning site with a lik that they must login first).
Store a timestamp of when this request happend.
On your OpenID callback check whether the session variables are set and redirect the user to the stored query. Check the timestamp (don't redirect if the timestamp is older than 5 minutes or so). After that clear both variables from the session.
This will lead to odd behaviour if the user violates against the assumption, but I don't think there is any way you can circumvent that.