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.
Related
I want to use FirebaseUI in redirect mode, as opposed to the current popup mode I'm using. But I don't want to have a separate dedicated login URL, instead I want the user to be able to log in from any URL (using a custom dialog as the UI container for FirebaseUI).
The problem I run into is that when starting the login process, I show the dialog and the user selects their auth provider, gets redirected to the auth website, but then they are redirected back to the original URL on my website.
Now the UI container dialog is not displayed and firebaseUI.start() doesn't get called because the webpage doesn't know that the user is in the process of logging in. The result is that nothing happens - the user is halfway through the login process.
Is there any way I can specify a URL for the first redirect? I'm not talking about the final signInSuccessUrl config parameter, but something similar for the first redirect back to my website?
That way I'd be able to send the original URL that started the login process along with a flag or something that tells the webpage that the user is in the middle of a login flow so that it can display the login process UI container and call firebaseUI.start() to perform the last redirect.
You can start FirebaseUI from any URL but the underlying signInWithRedirect always return to the same URL. Calling start on redirect will complete the sign in. If you have some condition, where you don't always display the sign in UI, you can use some flag pendingRedirect which you save in sessionStorage and check before rendering the UI to complete the sign-in on return. You would clear that after rendering.
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
I am new to liferay 5.1 technology.
I by mistake removed the login portlet and now I am not able to login into the application.
I mean login portlet is no more visible any help would be of great help.
Can you please try hitting the following url?
localhost:8080/c/portal/login
Replace host and port with your host and port number.
If it doesnt work out try doing the following.(Make sure the package is correct as i am not aware of package path in 5.1)
http://www.liferay.com/community/forums/-/message_boards/message/5005621
Actually, with enough persistence, it would be also possible to lock yourself out of access to /c/portal/login (as of Liferay 6.0.6). This can be done by setting community home page to a hidden "redirect" page (as opposed to default "portlet" page), causing /c/portal/login to redirect wherever the home page redirects.
Liferay tries to prevent from doing so by issuing alerts whenever you try to make home page hidden. But you can make some page hidden and then drag&drop it to the first position in site map root level.
The reason behind doing so is to achieve a certain appearance of portal navigation (which would otherwise require some mangling in theme), i.e. make home page redirect to one of it's children.
Going back to the topic, when /c/portal/login fails, there is one another, more reliable (yet more ugly) method of getting to what one would call a login page - append this: ?p_p_id=58&p_p_state=maximized to any non-redirecting Liferay page (and probably drop any other GET parameters if existent). This is also basically what /c/portal/login does - but it appends it to home page, so if home page is a redirect page it fails display login portlet in it's maximized state.
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.