Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Must log in twice to post #69

Open
ronsavage opened this issue Apr 20, 2010 · 4 comments
Open

Must log in twice to post #69

ronsavage opened this issue Apr 20, 2010 · 4 comments
Labels

Comments

@ronsavage
Copy link

Hi Folks

I logged in to blogs.perl.org. Then I clicked on Post and it asked me to log in again.

@briandfoy
Copy link

I continually have the same problem.

@benkasminbullock
Copy link
Contributor

This problem is continuing in 2021.

When one clicks the "Sign in" button at the top, an mt_commenter cookie is returned. When one then clicks Post, there is another "Sign in" page which then goes on to set an mt_user cookie. So the authentication at the top of the page is for mt_commenter authentication and a further mt_user cookie is required also.

There is some source code here:

https://github.com/movabletype/movabletype/blob/master/lib/MT/App.pm

I don't know if it's possible to log in mt_user cookie from the top "Sign in".

@benkasminbullock
Copy link
Contributor

It looks from the template source code like the top page "blogs.perl.org" is set up as another blog within Movable Type, then the "Sign in" link there sends people to a commenter login where they log in as "commenters" to the main blog, but then when one wants to post to one's own blog, the link to "Post" from the top page sends one to one's own blog's login page, which is why there are these two kinds of cookies.

@ap
Copy link

ap commented Mar 14, 2021

Thanks for that pointer. Note that one login page is rendered by mt.cgi, the other is rendered by mt-cp.cgi. The mt.cgi login sets mt_user while the mt-cp.cgi login sets mt_commenter. I’m not yet certain that the difference in which cookie is set depends on which script is showing the login page, but it seems very likely, since it doesn’t seem like any request parameter affects which cookie each of them will set. I’m guessing the least-effort fix is going to be to make both scripts set both cookies, though that will have to be seen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants