I changed my code from calling on this function: wp_logout_url() when the logout button is clicked, to just calling www.mysite.com/access?action=logout.
Users could log out and they get a prompt before they do but is there any vulnerabilities letting users log out of the website this way? Rather than using wp_logout_url()?
Related
I'm trying to migrate to the new Sign In With Google and I'm missing one crucial functionality I was using previously.
Basicly my application is working with locally created application users. At one point in the application, the user is prompted to login with Google Account to confirm that he's the correct user that will do some Google API action. I was able to achieve that with following code from the soon deprecated Google Sign-In library:
const auth = gapi.auth2.getAuthInstance();
if (!auth.isSignedIn.get())
await auth.signIn({
prompt: "select_account",
login_hint: employeeEmail
});
...
And it worked just fine. Now all the above methods are being deprecated and there are no direct replacements, or at least I don't understand how to achieve the same result. I am able to confirm the user identity by checking the id token received by using:
google.accounts.id.initialize({/*options*/);
...
google.accounts.id.prompt();
But if there's no google session active for the user, nothing happens.
The only way to actually trigger the Sign In is to click the Google Sign In Button, rendered using:
google.accounts.id.renderButton(htmlElement, {/*options*/});
After the button is clicked, the sign in popup is shown and everything is fine, the callback of the initialize configuration is called and the flow is resumed.
The problem is, how do I trigger the Sign In popup programatically? All of the above starts with a specific button click on my website.
FYI
I actually managed to reproduce almost the same behavior with the new API. It might not be the most elegant way of doing this, but I replaced the signIn method from my post above with google.accounts.oauth2.initTokenClient. Even though it should be used to only receive the tokens, it will also create a valid Google session that then can be detected by using silent auth (prompt: "none");
I’m working with a vuejs project and I’m using firebase oauth authentication.
I’ve already implemented the sign in with popup flow, and the auth state change event listener, it works pretty well.
The thing is, after I sign in, when I refresh/first load the application, as the auth session persists, there’s a time span between the app load and the auth state change is triggered, so even though I’m logged in, I see the login screen for a few seconds before the event is fired and I get redirected to the main page
For example
I open the application
As I’m not authenticated, I get redirected to /login
I see the login screen
I sign in using the google provider and the popup
I get redirected to the main page /
I refresh the page
I get redirected to /login
As I was already authenticated, the authStateChange event fires and I get redirected to the main page, but this happens after a couple seconds
There’s any way to handle that previous state to be able to show a “loading...” or something? I’ve been reading the docs but the only thing I found is using the event listener that I’m already using
Thank y’all in advance!
Okay y’all, this is the solution I came with:
There’s no way to know if an user will ve logged in until it gets actually logged in and the authStateChange event fires. So the best I could do is, when the user logs in into the application, I store a “EXPECT_LOGIN” value in localStorage, so if I reload the app, and that value it’s true i show a “Loggin in” message with a timeout of, say, 5 seconds. Here we have two possibilities:
The event is fired and the user is logged in automatically
The timeout is fulfilled and I set the “EXPECT_LOGIN” value to False, then I let the user login manually
I have a Specflow/Gherkin test to test an Asp.net application that involves logging into to perform an action using Selenium (and FireFox). Above my controller action I have the [Authorize] token and the site performs as I expect when manually testing. My login uses Forms Authentication.
My test goes as follows:
Navigate to Login page
Provide user and password
Click Login
Navigate to Create Product page (must be logged in)
Enter product detail
Save button
Check item is in database
What looks to be happening is steps 1-3 are fine. But when I execute Step 4, it is redirecting to the login page again. So Step 5 fails, as that isn't the page that is expected.
If I Start at Step 3 and login on the redirect, it works fine e.g.:
Navigate to Create Product page
Provide user and password
Click Login
Enter product detail
Save button
Check item is in database
Is there something specific I need to add to Selenium to make it save the session/login token?
When we're writing a BDD test either with Specflow, Cucumber or any other tool, we need to center our focus on what the end user needs to do to get the scenario done, in other words: the "As a user" perspective.
So in your scenario, as a user if he needs to navigate to loginPage, login and then navigate to createProductPage and login again, so be it! If that's true, write steps that would login again.
If not, on the other hand, if the user needs to login one single time, you don't need to store a session or anything else, I think in this case you have a bug in your application.
PS: if that wont work you can store a profile of your browser with the authentication token and use it, because when a browser gets instantiated it gets a clean browser profile.
OK so it transpires that the transition between steps 3 and 4 are happening too quick. So once I Login, i should verify the page title for example (as it redirects back to the Home page) and then proceed to the Create. Step 4 happens too quick to save the cookie/session.
I am using meteor user accounts for login . Now I have customized login forms and used their methods to login. Now i want to add remember me check box. If its not selected user should be logged out. Otherwise he can resume his session unless he manually log out. Any idea or concept what ever you can provide would be appreciated.
Can not test this at the moment, but you could use onbeforeunload or onunload events, and process the logout in that step
window.onbeforeunload = function () {
Meteor.logout();
};
I've just finished implementing a modal dialog login popup for my ASP.NET website. The experience is similar to what you get with DIGG.com. When you log in, you get a fancy popup modal dialog (provided by the JQuery Tools Overlay control). The dialog is an ASCX file in the Master Page, so it's available globally. It uses a PageMethod to validate the current user. If the validation succeeds, I call window.location.reload(); in the PageMethod's success callback.
This works great when logging in on a page that doesn't require authentication, but what about when non-auth users are trying to navigate to a page that requires auth?
Is it possible to modify my web.config file so that instead of redirecting to a SignIn.aspx page for non-authenticated users I simply invoke the modal dialog instead?
Let's say a non-authenticated user is on Default.aspx which doesn't require auth. He wants to navigate to "Add.aspx" which does require auth. What's the best way to handle this with a modal dialog popup?
If I have to use a dedicated page, I guess I'll just have a SignIn.aspx page that invokes the dialog when it loads and if authentication succeeds, it'll use JavaScript to redirect to the destination page.
But ideally, I'd like to do the login from the Default.page and then redirect to "Add.aspx" with script.
Since I didn't get any feedback and went ahead and "solved" this issue conventionally. I still have a dedicated Login.aspx page but it's only used in cases where users navigate directly to a page requiring authentication.
In this case, I let ASP.NET redirect to the Login.aspx, and then using client script I invoke the popup dialog. I do the normal authentication using a WebMethod and then redirect as needed. If the user cancels the dialog, I just redirect back to Default.aspx.
Seems like there's no getting around the need for a dedicated Login page.