Tt-rss can't connect anymore via any client

Support
1

This problem was reported also in github page

With the new update for testing version of yunohost it is no more possible to connect via any client, android, desktop, while the web interface works normally.

As reported in github report, if I try the command

curl -d ‘{“op”:“login”,“user”:“insertuserhere”,“password”:“insertpasswordhere”}’ -L https://rss.example.net/api/

to my server with name and password I get this:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>YunoHost Portal</title>

  <!-- Responsive -->
  <meta name="format-detection" content="telephone=no" />
  <meta name="viewport" content="width=device-width, height=device-height, initial-scale=1" />

 <!-- Do not index SSOWat pages -->
  <meta name="robots" content="noindex, nofollow">

  <!-- Stylesheets -->
  <link rel="stylesheet" href="assets/css/ynh_portal.css">
  <link rel="stylesheet" href="assets/themes/default/custom_portal.css">

  <!-- Icons -->
  <link rel="shortcut icon" href="assets/icons/favicon.ico">
  <link rel="apple-touch-icon" sizes="57x57" href="assets/icons/apple-touch-icon-57x57.png">
  <link rel="apple-touch-icon" sizes="114x114" href="assets/icons/apple-touch-icon-114x114.png">
  <link rel="apple-touch-icon" sizes="72x72" href="assets/icons/apple-touch-icon-72x72.png">
  <link rel="apple-touch-icon" sizes="144x144" href="assets/icons/apple-touch-icon-144x144.png">
  <link rel="apple-touch-icon" sizes="60x60" href="assets/icons/apple-touch-icon-60x60.png">
  <link rel="apple-touch-icon" sizes="120x120" href="assets/icons/apple-touch-icon-120x120.png">
  <link rel="apple-touch-icon" sizes="76x76" href="assets/icons/apple-touch-icon-76x76.png">
  <link rel="apple-touch-icon" sizes="152x152" href="assets/icons/apple-touch-icon-152x152.png">
  <link rel="icon" type="image/png" href="assets/icons/favicon-196x196.png" sizes="196x196">
  <link rel="icon" type="image/png" href="assets/icons/favicon-160x160.png" sizes="160x160">
  <link rel="icon" type="image/png" href="assets/icons/favicon-96x96.png" sizes="96x96">
  <link rel="icon" type="image/png" href="assets/icons/favicon-16x16.png" sizes="16x16">
  <link rel="icon" type="image/png" href="assets/icons/favicon-32x32.png" sizes="32x32">
  <meta name="msapplication-TileColor" content="#41444f">
  <meta name="msapplication-TileImage" content="/mstile-144x144.png">
</head>
<body class="ynh-user-portal ">

  <div id="ynh-logo" class="ynh-logo">
    <span class="element-invisible">Yunohost</span>
  </div>

  <div class="content">


    <div class="wrapper messages info">Per favore, accedi per visualizzare il contenuto</div>
<div class="ynh-wrapper login">
<form class="login-form" name="input" action="" method="post">
  <div class="form-group">
    <label class="icon icon-user" for="user"><span class="element-invisible">Username</span></label>
    <input id="user" type="text" name="user" placeholder="Username" class="form-text" autofocus required>
  </div>
  <div class="form-group">
    <label class="icon icon-lock" for="password"><span class="element-invisible">Password</span></label>
    <input id="password" type="password" name="password" placeholder="Password" class="form-text" required>
  </div>
  <input type="submit" value="Log in" class="btn classic-btn large-btn">
</form>
</div>

  </div>

  <!-- Scripts -->
  <script src="assets/js/ynh_portal.js"></script>
  <script src="assets/themes/default/custom_portal.js"></script>
</body>
</html>
2

I have the same issue

Yunohost version: 3.7.0.1 (testing)

3

I am using testing yunohost on amd64.

I cannot check because I don’t know well nginx but in the github report csolir write that this a problem of nginx

4

OK, bug reproduced, and truly linked to YunoHost 3.7 SSOwat refactoring.
The app settings:

  • domain --> unprotected_uris
  • domain/api, domain/public.php, domain/opml.php?op=publish --> skipped_uris

The skipped uris aren’t reachable unless logged in… That can be worked around if the domain is removed from unprotected_uris.

I’ve not followed the recent changes in SSOwat, can that be a bug or is the SSOwat configuration to be adapted, following the permission mechanism implementation?
cc @Aleks

5

:up:
@Aleks do you see any link with recent changes?

Thanks!

6

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.

7

So there’s a fix on the way, thanks for the feedback that allowed to find this bug :

1 Like
8

Works great, thanks! :heart:

2 Likes