Weblate: Active login at codeberg.org not recognized by translate.codeberg.org #1415

buhtz commented 2024年01月22日 07:55:28 +01:00

Comment

I am sorry, for giving such a broad and unclear Issue. I assume there are not enough technical details to help you fixing it directly. But the described behavior do affect my translators often. So I report it like user story.

This is not about the registration process. This is hard enough for some of my translators. But even when they registered at https://codeberg.org and logged in at https://codeberg.org, Weblate itself doesn't recognize that active login.

Because of that the translators telling me that they registered and logged in but they can not find the buttons etc ("Approved" checkbox, "Not sufficient privileges to save translations", ...). Keep in mind that translators often none-technical person.

It might be the case that add-blockers or cookie-blockers might be involved in this Issue. But this is not for sure.

Thanks a lot for working on Weblate at all. Weblate at Codeberg is IMHO currently the only acceptable translation solution for FOSS projects without money. There is much value in it. And I hope you keep that service up and running no matter that its maintenance is far away from being easy.

### Comment I am sorry, for giving such a broad and unclear Issue. I assume there are not enough technical details to help you fixing it directly. But the described behavior do affect my translators often. So I report it like user story. This is not about the registration process. This is hard enough for some of my translators. But even when they registered at https://codeberg.org and logged in at https://codeberg.org, Weblate itself doesn't recognize that active login. Because of that the translators telling me that they registered and logged in but they can not find the buttons etc ("Approved" checkbox, "Not sufficient privileges to save translations", ...). Keep in mind that translators often none-technical person. It might be the case that add-blockers or cookie-blockers might be involved in this Issue. But this is not for sure. Thanks a lot for working on Weblate at all. Weblate at Codeberg is IMHO currently the only acceptable translation solution for FOSS projects without money. There is much value in it. And I hope you keep that service up and running no matter that its maintenance is far away from being easy.

Gusted commented 2024年01月22日 12:48:38 +01:00

Because of that the translators telling me that they registered and logged in but they can not find the buttons etc ("Approved" checkbox, "Not sufficient privileges to save translations", ...).

This sounds like an UX issue of Weblate, but given your other sentence:

It might be the case that add-blockers or cookie-blockers might be involved in this Issue. But this is not for sure.

It sounds like a bug. So translators should have permissions to do certain action on a Weblate project, but didn't had this permission to do so (possibly because of Codeberg not giving this authorization?). Sorry, I'm just having a bit of a hard time understanding the exact issue here.

> Because of that the translators telling me that they registered and logged in but they can not find the buttons etc ("Approved" checkbox, "Not sufficient privileges to save translations", ...). This sounds like an UX issue of Weblate, but given your other sentence: > It might be the case that add-blockers or cookie-blockers might be involved in this Issue. But this is not for sure. It sounds like a bug. So translators should have permissions to do certain action on a Weblate project, but didn't had this permission to do so (possibly because of Codeberg not giving this authorization?). Sorry, I'm just having a bit of a hard time understanding the exact issue here.

buhtz commented 2024年01月22日 12:52:01 +01:00

Sorry, I was unspecific.
When the user logged in in Codeberg.org but not in translate.codeberg.org it sometimes happens that translate.codeberg.org do not recognize the codeberg.org logging. The translate.codeberg.org website in this case looks like not logged in.
In this situation clicking on loggin in the login site does not comes up. But the recognition process is initiated and translate.codeberg.org does find out that the user is still logged in at codeberg.org.

Sorry, I was unspecific. When the user logged in in Codeberg.org but not in translate.codeberg.org it sometimes happens that translate.codeberg.org do not recognize the codeberg.org logging. The translate.codeberg.org website in this case looks like not logged in. In this situation clicking on loggin in the login site does *not* comes up. But the recognition process is initiated and translate.codeberg.org does find out that the user is still logged in at codeberg.org.

Gusted commented 2024年01月22日 13:04:27 +01:00

When the user logged in in Codeberg.org but not in translate.codeberg.org it sometimes happens that translate.codeberg.org do not recognize the codeberg.org logging.

That sounds right, translate.codeberg.org can only know if a user is logged in after the user clicks on 'sign in', stored cookies are not shared between translate.codeberg.org and codeberg.org.

In this situation clicking on loggin in the login site does not comes up. But the recognition process is initiated and translate.codeberg.org does find out that the user is still logged in at codeberg.org.

That would be the case if the user already approved the OAuth application of translate.codeberg.org in codeberg.org, in that case the request to codeberg.org would directly be redirected back to translate.codeberg.org with the authorization token, thus looking like it never went to codeberg.org

> When the user logged in in Codeberg.org but not in translate.codeberg.org it sometimes happens that translate.codeberg.org do not recognize the codeberg.org logging. That sounds right, translate.codeberg.org can only know if a user is logged in after the user clicks on 'sign in', stored cookies are not shared between translate.codeberg.org and codeberg.org. > In this situation clicking on loggin in the login site does not comes up. But the recognition process is initiated and translate.codeberg.org does find out that the user is still logged in at codeberg.org. That would be the case if the user already approved the OAuth application of translate.codeberg.org in codeberg.org, in that case the request to codeberg.org would directly be redirected back to translate.codeberg.org with the authorization token, thus looking like it never went to codeberg.org

buhtz commented 2024年01月22日 13:13:04 +01:00

That sounds right, translate.codeberg.org can only know if a user is logged in after the user clicks on 'sign in', stored cookies are not shared between translate.codeberg.org and codeberg.org.

From a users perspective this is IMHO a bug.

if the user already approved the OAuth application of translate.codeberg.org in codeberg.org

How can I do this? What exactly is OAuth?
Do you mean that if the OAuth thing is activated that the user do not have to click on "sign in" explicit?

> That sounds right, translate.codeberg.org can only know if a user is logged in after the user clicks on 'sign in', stored cookies are not shared between translate.codeberg.org and codeberg.org. From a users perspective this is IMHO a bug. > if the user already approved the OAuth application of translate.codeberg.org in codeberg.org How can I do this? What exactly is OAuth? Do you mean that if the OAuth thing is activated that the user do not have to click on "sign in" explicit?

fnetX commented 2024年01月22日 13:25:26 +01:00

The user on translate.codeberg.org always needs to press the "Sign in" button. The request goes to Codeberg. If the user does this for the first time with their account, they are asked to authorize the Weblate server to access user data. If they already did this once, they are immediately redirected. In both cases, they are now logged in as seen by Weblate.

This workflow is hard to change and is exactly the behaviour across hundreds of companies, high school networks and other organizations.

The user on translate.codeberg.org always needs to press the "Sign in" button. The request goes to Codeberg. If the user does this for the first time with their account, they are asked to authorize the Weblate server to access user data. If they already did this once, they are immediately redirected. In both cases, they are now logged in as seen by Weblate. This workflow is hard to change and is exactly the behaviour across hundreds of companies, high school networks and other organizations.

buhtz commented 2024年01月22日 14:05:40 +01:00

Thanks for explaining.
Please close it if you see no option or resources to fix this.

From a users perspective: That "others" do it the same way does not make it right.

And myself I am not aware of another example of that behavior and I do work in multiple big environments offering multiple services all with the same account. But I also accept that I might be an exception. ;)

The point is that Codeberg is Codeberg. Users do not know or care that there are several servers involved. They see no difference between the translation platform and the code hosting platform.

Thanks for explaining. Please close it if you see no option or resources to fix this. From a users perspective: That "others" do it the same way does not make it right. And myself I am not aware of another example of that behavior and I do work in multiple big environments offering multiple services all with the same account. But I also accept that I might be an exception. ;) The point is that Codeberg is Codeberg. Users do not know or care that there are several servers involved. They see no difference between the translation platform and the code hosting platform.

fnetX commented 2024年01月22日 14:30:32 +01:00

A potential option could be to force the login. That is also sometimes the case e.g. at my university. If Weblate would automatically redirect to Codeberg and require an account, the user would likely not notice. However, it would break anonymous access / contributions.

I don't know if there is a way to have the OAuth flow work in background (the redirect game). And in case there is no redirect back, it is ignored.

A potential option could be to force the login. That is also sometimes the case e.g. at my university. If Weblate would automatically redirect to Codeberg and require an account, the user would likely not notice. However, it would break anonymous access / contributions. I don't know if there is a way to have the OAuth flow work in background (the redirect game). And in case there is no redirect back, it is ignored.

Bubu commented 2024年12月08日 23:23:45 +01:00

I'm going to close this, as I think @fnetX sufficiently described the situation in #1415 (comment)

I'm going to close this, as I think @fnetX sufficiently described the situation in https://codeberg.org/Codeberg/Community/issues/1415#issuecomment-1529547