Hi Dany, which version are you using? 7.0.0 or 7.0.1?

Whoops, forgot to mention I'm on 7.0.1.

Hi Dany,

I've tested this in 7.0.0, 7.0.1 and with latest codebase and can't replicate the issue. We fixed an issue with the login http post with query strings in 7.0.1 but even before that fix I'm not sure how the URL would be redirected to the one you've listed.

Given this URL: http://bmdcnz/umbraco/?username=admin&password=_#/login?check=false

This would mean that you've been redirected to that URL since angular only updates the part of the URL after the hash(#).

Is there any chance you can replicate this issue?

Also note that a 400 response is normal and we return this response code for any validation failures.

I have had this happen at least twice before I noticed the query string. I will try to remember what happened in details if it happens again.

It happened again! I have deployed the basic draft skeleton of the site on shared hosting. I have left the session running for a while so I assumed it had expired perhaps? I went to refresh Stylesheet node tree, a browser login dialog popped up, I clicked cancel, I was sent back to the backoffice login screen and the URL was:

http://bmdcnz.codedog.info/umbraco/?username=admin&password=password#/login?check=false

Hi, what I'm not understanding is the part "a browser login dialog popped up". Are you using some sort of Basic Authentication on your IIS website? We don't have any sort of login dialog 'pop-up' in v7 and we don't have a 'cancel' button so I'm assuming this dialog has to be something outside of v7. Please let me know any other details you have.

I think that IIS authentication part is a bit of a red herring. I don't have any kind of authentication enabled on the shared hosting. Not sure what happened there. When this URL was visible on my dev machine at home I had no such IIS authentication dialog popping up.

Ok so was this login dialog like an IIS auth dialog? If so, at least that's a start to see if Basic Auth is doing some very strange things with the redirect (still seems very weird though since the password is POSTed)

Yes, it was very much like an IIS auth dialog. That has never happened on my dev env - only on the shared hosting. I figured authentication would be a POST request. That means the data should be in the body, not part of the URL, right?

Indeed, but unfortunately the way that the URLs were being created in 7.0.0 had the password in a query string in some cases, this was fixed in 7.0.1 - please make sure you are running 7.0.1 and not 7.0.0 and ensure that all of the client files in the /Umbraco folder were replaced when you upgraded.

I'm definitely running 7.0.1. I started with an empty MVC project and installed the Umbraco Cms nuget package. At least that's what the nuget package says. I assume the right build of Umbraco went into that package and the Umbraco Core prerequisite? ;o)

I do find it a bit weird that I'm having this problem, yet nobody else seems to be mentioning it.

If you can check this file:

/umbraco/js/umbraco.resources.js

on line 28 or so you should see this

return umbRequestHelper.resourcePromise(
    $http.post(
        umbRequestHelper.getApiUrl(
            "authenticationApiBaseUrl",
            "PostLogin"), {
                username: username,
                password: password
            }),
    'Login failed for user ' + username);

Can you verify that looks like that and not like this:

return umbRequestHelper.resourcePromise(
    $http.post(
    umbRequestHelper.getApiUrl(
        "authenticationApiBaseUrl",
        "PostLogin",
        [{ username: username }, { password: password }]))),
'Login failed for user ' + username);

let me know!

It does indeed look like the former, not the latter.

It does indeed look like the former, not the latter.

Well that's at least good news :)

The username/password are POSTed then, can you check that this is the case on both your dev and the server you are having trouble with?

Otherwise I'll have to see if i can replicate with IIS and Basic Authentication

That particular snippet are the same both on dev and server. I don't think I have Basic Authentication enabled on either environment. I have Anonymous enabled, and Forms auth.

I can see at least one problem here: the username and password during a POST are also just attached to the URL as a querystring. So I'm seeing: /umbraco/UmbracoApi/Authentication/PostLogin?username=admin&password=mypassword

So essentially it's still doing a GET through the POST verb.

Sebastian, it used to do that in 7.0.0 but is fixed in 7.0.1

just tested again to make sure, these are not passed as query strings in 7.0.1

@Shannon ah, damn, you're right, I was seeing this on a slightly older build of 7.0.1.. never mind, a clean install of the final works properly.

We're on 7.2.8, use Okta to provide login credentials via SSL/ActiveDirectory, and a user just saw his password appear in the URL after the login screen had passed. URL looked sort of like: https://www.domain.org/umbraco?username=cm%40domain.org%password=____#/content

It's not a frequent occurrence (first I'd heard of it), but thought we'd mention it.

I am not familiar with Okta but I would suspect that the issue is part of that integration.

When logging in normally, the Umbraco core absolutely only POSTs the login data with no query strings, you can see the following requests:

Unsuccessful login:

Successful login:

And during this process there is no redirecting so the user would not see any changes to the query string format of the address.

If you can provide steps to replicate with whatever integration you are doing with Okta I can attempt to help solve the issue.

is working on a reply...