I have a login form that send the login info with Ajax.
If the login is wrong, I send a .js that shows some alert and shakes the form.
If the login is successfull, I simply want to redirect the full page.
The Rails controller expect always a .js call, and actually in both cases I send a .js reply, because the redirect in rails will go into some .js reply that the browser expect.
login wrong:
$("#login").effect("shake", { times:2 , distance:10},20);
login successfull:
window.location.replace("<%=root_url(:only_path => false)%>enterprises/");
The question is if this is a good approach (personally I don't like it but it works) or are better ways to handle this.
thanks,
I think it is a good solution. Mayby I would fix the url in case of a successful to depend on a helper, instead of a hardcoded path, but it is a minor thing.
Maybe it can be good to have an additional .html view on both actions in case of the user disabled the javascript in the browser.
Related
I have a question regarding the logout route. When you look at the Demo Page when the user is logged out, a 404 error is shown in the console, because the CMSPageGuard tries to fetch the non-existing Logout page from the Backend. This is a minor problem but doesn't seem intentional?
More so since the logic in the Logout guard redirects to either 'home' or 'login' in case the logout path doesn't exist.
Is the only workaround to not get the 404 error to add a logout page in the Backend, even though it is never shown?
In short, this is intentional. It is part of a feature that makes it easy for storefronts that do require the optional logout page to add it in the CMS and it will be picked up out of the box by the Spartacus logout logic.
You are right about what happens under the hood. If you look at the description of the LogoutGuard in the doc, the overall logic its described like so:
Takes care of routing the user to a logout page (if available) or redirects to the homepage. If the homepage is protected, the user is redirected to the login route instead.
To verify if a logout page is available, the LogoutGuard makes a request for it. If a logout page is not available, that request returns a 404 and this is what shows up in the browser dev tools.
As for preventing that these errors show in the log, there is for now no configuration that will turn this feature off. You might explore using a custom LogoutGuard and override the canActivate function, but I'm not 100% sure this is possible.
I have spent a significant amount of time searching for a solution here and can't find one. Here is the situation:
I am using the built-in Cognito UI
When I redirect my app to the UI with response_type=code, I get to the login page fine. When I enter my credentials and click "Sign In" the post request to the /login cognito endpoint results in a 405 method not allowed
If I instead redirect my app with response_type=token, it redirects to my return_url with no problem, but the parameters are harder to retrieve as they are hash parameters instead of query parameters.
I am actually a little surprised either one works because the documentation seems to indicate the /login endpoint is GET only: https://docs.aws.amazon.com/cognito/latest/developerguide/login-endpoint.html
I'd prefer to use the code response_type anyway. Am I doing something wrong here? Is anyone else having this issue? I don't think I'm doing anything unusual. It feels to me like something is just broken in the built-in ui flow. I have definitely discovered that I should not be using the built-in UI, but I'd like to get this working and then replace it if possible.
Please let me know if you need more information and I'd be happy to provide it.
EDIT: It actually does work if I make the redirect_url google.com, which means it's something with my app and the redirect, but there is basically no indication about what is wrong. Anyone know where I can find any kind of relevant logs or information related to these types of errors in Cognito?
Alright this appears to be a bug in the built-in UI and I'll file it with Amazon. I finally figured out that my redirect_uri I was sending over had a trailing slash and the one I configured in Cognito did not have a trailing slash. It works when I remove this.
The reason I believe this is a bug is because normally when I pass in an invalid redirect, the UI immediately sends me to a page with that error. When the only difference is a trailing slash, I can go through the login flow fine, but it hits that 405 method not allowed error when trying to redirect back to my flow.
Not sure if anyone else will run into this very odd edge-case, but hopefully this is helpful if you do.
I'm using mvc4 and .Net 4.5 in my project with SSL. Now, on localhost and even on server, the login page gets redirect a bunch of times and then loads without and css on page. In browser debugger I get error as:
Uncaught SyntaxError: Unexpected token <http://localhost:55248/Account/Login? ReturnUrl=%2fbundles%2fjqueryval%3fv%3dWrBNyT_GYLXAZ7iWD7vDdFccq24m7v_9MPi3rcQ8FO01&v=WrBNyT_GYLXAZ7iWD7vDdFccq24m7v_9MPi3rcQ8FO01...
I'm using bundling and code snippet as below.
bundles.Add(new ScriptBundle("~/bundles/BaseJs")
.Include("~/Scripts/jquery-{version}.js")
.Include("~/Scripts/jqueryui/jquery-ui.js")
.Include("~/Scripts/bootstrap.js"));
The syntax error is from the error page being loaded as JavaScript (when it's obviously not JavaScript). It's a red herring. The true problem is that your JavaScript file is needing authorization in the first place.
Typically, this wouldn't be an issue. By default, anything with an extension (.js, for example) is ignored by MVC and handled directly by IIS. Worst case scenario, there, IIS doesn't have permission to read the file, and you end up with a 403 Forbidden. It would end there, as an IIS-level 403 would not trigger a login page redirect, mostly because, again, MVC is not involved.
However, if you've bungled around the with default setup, such that MVC is now handling all requests, even for static files. Then, the action that's being triggered to handle the request to your JavaScript file is requiring authorization, and therefore is redirecting to the login page. So find out what action is being hit and either remove the requirement for it to be authorized or have the right action serve the file. Or, ideally, leave things as they should be and let IIS do what IIS does best and serve the static files.
EDIT
I wasn't paying attention to the fact that bundles are rendered without a file extension. However, the steps to correct the issue are largely the same. Something is mostly likely off with your routing, and the request for the bundle is actually being caught by one of your actions, particularly one that requires authorization. Look out for catch-all routes and make sure that you're not using a route like "bundles" anywhere in your RouteConfig.cs or any of your Route attributes, if you're using attribute routing.
First try to include your bundles like that :
.Include( "~/Scripts/jquery-{version}.js",
"~/Scripts/jqueryui/jquery-ui.js",
"~/Scripts/bootstrap.js"
);
Include takes string[] as parameter and you don't need to call include for each row. Then you should debug your bundles to see which js is giving the error.
Try to comment out rows 1 by 1 to see what would be the result. The problem is definatelly in your bundles, I also had these kind of errors. If you can provide more code - > snippet from the view, of the css loading and bundles and stuff like that I would be able to help you more.
I need help figuring out how to allow users who login go back to the page that they were on before being sent to the login page. Here is a quote from my boss:
Sometimes I forget to sign in and I go to a page, click and get the
notice about joining or signing in. That is fine, but is there a way,
once I sign in to open the page I was trying to open prior to signing
in, instead of having to go through all the navigation again?
I'm using PHP to do this project.
Whatever mechanism forwards the user to the sign-in page should include the original page's URL as a parameter. Something like:
header('Location: http://example.com/login.php?redirectTo=' + urlencode($_SERVER['REQUEST_URI']));
Then the login.php page can redirect to that page after the user authenticates:
header('Location: ' . $_GET['redirectTo']);
You may want to put in some checking on the redirectTo value in login.php to make sure nobody's trying to do anything malicious, I suppose. Though I can't currently think of anything malicious they could do. (Though you would want to include a default if no URL was provided.)
But the general idea is that the authentication mechanism provides the login page with a redirect URL when it detects that the user needs to login.
I have been trying to do this for days now and cant seem to find any help on how to do is. I want the user after login to be redirected to a different page instead of the members landing page.
Try checking the code in User/AuthController after this comment Run post login hook. There are several ways to do a custom redirect here.
specify a return_url parameter in the link to login page. You can also 64-bit encode the redirect url so that it is compact.
Keep a session variable, namely Zend_Session_Namespace('Redirect')->uri
Write a post login hook onUserLoginAfter and pass a redirect parameter in its response.
If all else fails, hard-code the next line of code which redirects to home :P