This rocks. Thanks very much! Although I’ve noticed there’s 404 errors for the “special feed” favicons. I guess you should ignore those? It’s looking for things like ttrss/feed-icons/-3.ico for example.
just updated to the new version of tiny reader, and the program now throws an error that it no longer likes the wildcard certificate from my server (names don’t match.) I am running on an iPhone SE and iOS 11.3 beta and the old program worked fine. Safari also has no problem accessing the web server that uses the same certificate.
Is this expected behaviour or a bug?
Do you mean that the app try to search for icons that don’t exist ?
Well, the code search for icon_path + “/” + feed_id + “.ico”, so special categories may have no icons, but I don’t check (the error is just ignored). I can improve that to avoid unnecessary calls for 404 .ico files.
Yes, certificates should now be valid and not auto signed. This is for security reasons (and Apple always force apps to adopt good practice).
Another user said that he found a workaround by adding his certificate to the iOS system profiles (just like when you tell Safari to accept the certificate to access your page).
However, I think it’s a good idea to always have valid certificate (and with let’s encrypt it’s free and super easy).
Not an iOS developer, but if an app uses normal iOS APIs for getting HTTP content, then as long as the operating system can validate the certificate I’ve found apps just work.
If self-signed certificates are being use there are a couple of options. You can create a configuration profile, like you said, but if you’re not using the profile for anything else that can be overkill. You can just download and install the certificate directly from Mobile Safari onto the device. You can even download the certificate’s root CA (if one is using a custom, self-managed root certificate authority).
tl;dr
Put the PEM-encoded public certificate on a server somewhere, enter its URL in Safari, click Accept/Install as needed. From that point iOS should allow it. (You might need to go into Settings > General > About > Root Certificates and toggle the certificate to ON).
Except that it is a valid certificate. It’s not bad practice to use a self-signed cert on your own website where you are the only user. I know the certificate is valid because I’m the guy that signed it. You’re confusing industry best practice for “what works for a home user’s personal website.” A self-signed certificate is exactly as secure as a commercial cert, and is more trustworthy than a commercial cert.
While I applaud your desire to adhere to “best practice” generally, that’s not what you’re doing here. This change simply inconveniences your users at the same time you add an easy option for people to tip you.
Please revert.
Hi @Tiberius,
I found two more bugs.
If I am in darkmode and opening a page (i think without background) I cant read anything as you can see here:
the article link is: https://blog.fefe.de/?ts=a461750f
The other one is from the prior version:
I think if there are codes or quotes the content is scrolling horizontally.
The url of this article is: https://www.kuketz-blog.de/mail-ru-weitere-mail-app-versendet-passwort-an-betreiber/
thx in advance
Problem is @ratso7 did not say it was a self-signed certificate, he is talking about a wildcard certificate, with which you have one certificate for several subdomains.
Tiberius indicated that certificates should now be valid and not self signed. Also, looking at the app’s settings, the ability to allow self-signed certificates is no longer present. The entire thrust of the discussion is that the app has been modified to allow only certificates that are “valid as per industry best practice.” This excludes the wildcard certificates that you and the OP mention, and also self-signed certificates as Tiberius himself mentioned.
I am speaking to the self-signed certificates as brought up by the author of the software. Using one is just as secure as one signed by a public CA (the signature has nothing to do with the security, but rather the trust of the cert). And are more trustworthy than one signed by a CA because the person who signed it is the one using it. I’d refer you to DigiNotar, Trustico, et al, for examples of how “trusted CAs” are less trustworthy an authority when signing your keys than – you are.
This is not a case where enforcing “valid” keys signed by a commercial CA is necessary, or even adds value. We’re not Joe Random user ignoring a cert warning in our browser when surfing porn on the public Internet. We’re technical people who have setup TT-RSS and know what we’re doing when we say “Allow self-signed certificates” in the app.
I’m not a security expert, but Apple recommandation is to use such certificate only for test purpose. They say that there is always a risk with self-certificate (Technical Q&A QA1948: HTTPS and Test Servers)
I can add the option to allow self-signed certificate, but nothing can guarantee that Apple will not reject the app or that iOS will disabled self-signed certificate trust. For example, installing a CA from Safari no longer automatically trusts it (iOS 11, 12, and 13 installed certificates not trusted automatically (self signed) - Stack Overflow)
Ok, I probably need to add white background for source viewing.
The screen need to scroll because /cgi-bin… is considered as only one word, so the text can’t be wrapped.
Again, user ratso7 was talking about a wildcard certificate, not about a self-signed certificate. These things are totally unrelated!
Yes, it is a self-signed cert. I am using it for my own purposes. The old program had a toggle that allowed this kind of cert.
I have reverted back to the old version and will not be updating the program again.
Thanks anyway.
20chars
The screen need to scroll because /cgi-bin… is considered as only one word, so the text can’t be wrapped.
Hm. I dont know Swift but cant you do something like word-wrap: break-word;?
Well, the article is displayed in a web view, so perhaps I can improve the style of the html page.
This would be great, thx!
What about the suggestion of feader with the custom styling? I think this could be improved with a custom CSS. I also have problems with embedded youtube videos sometimes.
The beta phase is finished, the app is available on the App Store.
I don’t know if this is the place to post feature requests or not, but I’d like to request a change. The Recently read special feed in the app does not sort articles the same way as the web application.
In the web application, articles are sorted in last read order, with the most recently read article at the top. This makes it easy to get back to where you were in the event the network burps, the browser is closed, authentication timeout forces a relog, etc, whatever.
In the Tiny Reader iOS app, the Recently read special feed seems to sort things in the same order as All articles, or at least in an order that is not useful for getting back to the last thing you were reading.
I don’t know the SQL query the Recently read feed is using to display articles in the web app, but I can tell that it’s feed -6. If this way of displaying articles could be brought to the iOS app, it’d be greatly appreciated.
Thank you for your consideration!