Tested the hotkeys with Internet Explorer (I use Firefox) and they work too. It might just be you guys.
Posted under General
This topic has been locked.
I should probably clarify that both links I posted should always work with hotkeys because I made sure the necessary information in the URL query for the search (tags=) was present. If you're logged out and do your own search, navigation hotkeys shouldn't work for posts in a search but should work for posts in a pool.
Updated
巌窟王 said:
I should probably clarify that both links I posted should always work with hotkeys because I made sure the necessary information in the URL query for the search (tags=) was present. If you're logged out and do your own search, navigation hotkeys shouldn't work for searches but should work for pools.
I can confirm this behavior.
if options[:tags].present? && !CurrentUser.is_anonymous?
tag_param = "?tags=#{CGI::escape(options[:tags])}"When I am logged out tag backlinking is completely disabled. Navigation works only in Pools.
When I am logged in and I remove the ?tags= part manually, I get the same behavior as above.
But I highly doubt that Provence is browsing Danbooru as an anonymous user. Or did he try to use hotkeys on a clean link to a post (post #2405317)?
To avoid misunderstandings like the one that is likely to have occurred with user #479484 and post #2410333, it might be a good idea to change the titles of the "Flag" link in the sidebar and the flag reason dialog to "Flag (post) for deletion". Currently, the only reference to the fact that flagging sends the post to a deletion queue is buried in the dialog's fine print. People might be assuming that flags are a general-purpose way to call the attention of site staff.
Flopsy said:
To avoid misunderstandings like the one that is likely to have occurred with user #479484 and post #2410333, it might be a good idea to change the titles of the "Flag" link in the sidebar and the flag reason dialog to "Flag (post) for deletion". Currently, the only reference to the fact that flagging sends the post to a deletion queue is buried in the dialog's fine print. People might be assuming that flags are a general-purpose way to call the attention of site staff.
It doesn't seem 'fine' or 'buried' to me. It's just one user misusing the Flag ability...
But the post was misrated (S instead of Q). If they are just raging against vile filth, why start doing it now, after three months, on a single not particularly vile image? post #2379544 was also rated S instead of Q, and also got flagged for "NSFW" a month ago.
Is anyone able to tell whether these flags come from Safebooru?
Agent_3602 said:
I've been having a problem on mobile when I try to go to this site it always gives me a SSL Connection error. I mostly operate from mobile so this is practically barring me from the site.
Please test your browser's SSL/TLS implementation here and send me the results (screen capture / text only) via PM.
I need your user agent (listed at the very top) and an overview of the supported cipher suites (listed under "Protocol Features").
Temp/quick fix: Browse Danbooru via plain HTTP (http://danbooru.donmai.us).
Updated
Flopsy said:
But the post was misrated (S instead of Q). If they are just raging against vile filth, why start doing it now, after three months, on a single not particularly vile image? post #2379544 was also rated S instead of Q, and also got flagged for "NSFW" a month ago.
What they should be doing is fixing the rating of the image instead of flagging it.
reiyasona said:
Temp/quick fix: Browse Danbooru via plain HTTP (http://danbooru.donmai.us).
I'm worried that you can still log in like this. Also, I mentioned this before but the certificates don't work for the sonohara and hijiribe domains.
tapnek said:
I'm worried that you can still log in like this.
Type-kun wrote the following on GitHub:
No HSTS please. It's easy to forget about it, but there are local networks where HTTPS is blocked as a whole; no reason to deny those people access to danbooru.
tapnek said:
Also, I mentioned this before but the certificates don't work for the sonohara and hijiribe domains.
@Albert seems to have one single-domain certificate for danbooru.donmai.us and one for safebooru.donmai.us.
The other sub-domains (sonohara and hijiribe) do not have their own certificate. When you visit them the server offers the same certificate as for danbooru.donmai.us. This causes the error message:
sonohara.donmai.us uses an invalid security certificate.
The certificate is only valid for danbooru.donmai.us
Error code: SSL_ERROR_BAD_CERT_DOMAIN
So Albert would either need to buy [1] additional single-domain certificates or one expensive wildcard certificate (this would be overkill) to solve this problem.
However, Danbooru is mainly accessed via danbooru.donmai.us, so I don't see the need to secure the other sub-domains.
Where did you mention it btw.?
[1] There are also free Let's Encrypt certificates. :P
tapnek said:
I mentioned it pages ago in this very same thread. By the way, Let's Encrypt sounds like a good idea unless albert prefers to pay for his own certificates.
The only problem I see with using Let's Encrypt certificates is the strictly limited 90 day lifetime. @Albert would have to rely on auto renewal to circumvent this.
However, Danbooru's main certificate expires 2018-05-15. There is no reason to take action now.
tapnek said:
Got a problem staying logged in securely. If you do that even with the Remember Me option checked and you don't access Danbooru for a couple hours, when you access the main website again, you won't be logged on until you click Sign In and then the Sign In Securely option.
@tapnek Do you still have this problem?
Updated
justsomefreakingname said:
I have a problem which i think everyone does, its that the WASD navigation isn't even working anymore.
@justsomefreakingname
Is it working for one of the cases I listed below?
Updated
chodorov said:
I had no clue Danbooru supports HTTPS. Is there a chance at there being a user settings checkbox to have it enforced always when you are logged in?
@chodorov
Simply install HTTPS Everywhere. In many cases it will automatically navigate you to an available HTTPS version of a given website.
Updated
Pardon if this has already been mentioned, but it's fairly recent for me and I don't see it mentioned within the last page or two, so...
As of recently, Danbooru's been appending Unicode FFFD (the ?-in-a-diamond replacement character on my browser) to the end of all the commentaries I've opened to work on. If I don't delete the character, Danbooru adds another FFFD to the end of both the original and translated commentaries when I submit changes. If I open the commentary again after submitting changes, the FFFD is back at the end of both original and translated versions.
The initial FFFD is invisible to view when the commentary isn't open for editing. If more than one is appended, then all but one are visible even when the commentary isn't being edited.
I can understand the original FFFD originating if Pixiv's programming has altered recently so that something odd happens at the end of a commentary. However, it seems to happen whether the commentary is imported along with the image or separately copy/pasted, plus that doesn't account for Danbooru generating one at the end of the translation.
This hardly seems like a site-breaker or even disruptor, but it's still mildly annoying.