I'm writing a Web Application using ASP.NET 4.0 and C#. In my application when I logout the page redirects to the Default page. But when I click the back button in my browser, it goes back to the Web page that I was working even though I'm logged out.
How do I stop it doing this?
You could set cache headers in authenticated pages to avoid them being cached downstream on the client. Here's an article you may take a look at.
So you could set the following headers on authenticated pages:
Response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1));
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
This could also be done in a custom HTTP module to avoid repeating the code in all pages.
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 am developing a Blazor Server Side Application which I need to include cookie authentication. We created a custom login page component, but in order to create a cookie I need to call a Razor page to create the cookie.
Is there a way to call the razor page without doing a page refresh.
I tried using the UriHelper.NavigateTo but does not work with non Blazor component routes.
Then I tried with a Javascript call to do a window.location, but the issue is that this causes a browser refresh that makes all my instances to be recreated (like AppState, HttpClient), so all the information in these instances are lost (like httpclient headers, etc).
I expect to call the razor page to create a cookie, in a way that the httpclient and appstate scoped instance keep their values.
We tried the Identity scaffolding but it has a bug in the latest Preview 8
I've seen that bug, easily corrected. You can scaffold now. And otherwise,
the only problem that we have is that we could not find a way to customize the bland Login and Register pages.
maybe you could live with those 'bland pages' until the release, end of September?
The steps, based on a Preview8 server-side project with "Individual user accounts"
NB: it is a good idea to Commit-changes in Git before and after this
temporarily disable this line in Startup: // endpoints.MapBlazorHub<App>(selector: "app");
run the scaffolding wizzard, add any pages you want
uncomment the endpoints.MapBlazorHub() line again
remove Pages/_ViewStart.cshtml
fix Pages/Shared/_Layout.cshtml, the first line is missing an #using
fix Pages/Shared/_Loginpartial.cshtml, the second line is missing #inject
Compile and Run
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 have an MVC Web Api application running in vs2012, As the user requirment application should redirect to locked screen when application is idle for 30 second.Can anyone please guide me to solve this issue.
Web API cannot provoke redirects.
What you need to do is something on the client side (JavaScript) that detects the lack of activity during 30 seconds and then locks the screen, for example placing a CSS overlay. If you really want to redirect to a locked page, for example the login page, you need to change the browser url, like this: window.location.href = newUrl;. You should also terminate the user session at this point. If not, someone can write another URL of your application, and will be redirected to it with the authentication in the current session.
What you can do to enter the locked state is to use JavaScript's setTimeout. Set a timeout of 30 seconds with a callback to the locking script. And do something to reset the time out if you detect activity on the page, which usually involves subscribing to events.
The most difficult to implement is the dectection of activity in the page. You can see some ideas on this SO Q&A: Detecting idle time in JavaScript elegantly. See the highly voted answers, which include very interesting ideas.
The easest way in my opinoin to write this <meta http-equiv="refresh" content="30;URL='home.html'" /> in the header of your page
and set session time out in web.xml or web config to be equal 30
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.