You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

312 lines
14 KiB

{% set metaTitle = "FAQ" %}
{% set metaUrl = '/faq' %}
{% extends "_layout.njk" %}
{% set noJsMaxSizeInt = config.cloudflare.noJsMaxSize | int %}
{% set chunkSizeInt = config.uploads.chunkSize | int %}
Updated Updated some dev dependencies. --- Gulp will now build CSS/JS files during development into dist-dev directory, to prevent IDE's Git from unnecessarily building diff's. Added dist-dev to ignore files. --- The entire config fille will now be passed to Nunjuck templates for ease of access of config values. Root domain for use in Nunjuck templates will now be parsed from config. Better page titles. Updated help message for "Uploads history order" option in homepage's config tab. Added "Load images for preview" option to homepage's config tab. Setting this to false will now prevent image uploads from loading themselves for previews. Uploads' original names in homepage's uploads history are now selectable. Min/max length for user/pass are now enforced in auth's front-end. Improved performance of album public pages. Their generated HTML pages will now be cached into memory. Unfortunately, No-JS version of their pages will be cached separately, so each album may take up to double the memory space. File names in thumbnails no longer have their full URLs as tooltips. I saw no point in that behavior. Added video icons. Homepage's uploads history will now display video icons for videos. "View thumbnail" button in Dashboard is now renamed to "Show preview". Their icons will also be changed depending on their file types. Added max length for albums' title & description. These will be enforced both in front-end and back-end. Existing albums that have surpassed the limits will not be enforced. A few other small improvements.
2 years ago
{% set extensionsFilterMode = config.extensionsFilterMode %}
{% set extensionsFilter = config.extensionsFilter %}
{% block stylesheets %}
<!-- Libs stylesheets -->
<link rel="stylesheet" href="libs/fontello/fontello.css{{ versions[1] }}">
{{ super() }}
{% endblock %}
{% block content %}
{{ super() }}
<section class="section">
<div class="container has-text-left">
Improved albums public page cache and more Removed its dependency towards albums' editedAt property. Editing album's metas (name, description, etc) will no longer update its editedAt property. Instead it will now ONLY be updated when adding/removing files to/from it. Just like how it was meant to be, which was to be used to check whether it's necessary to re-generate their downloadable ZIPs. Albums public page cache will still be properly invalidated when adding/removing files to/from it, as well as after editing their metas. Added views/album-notice.njk to be used to render okay-ish notice when an album's public page is still being generated. I was originally thinking of using it for disabled albums as well, but I refrained from it to reduce the possibility of disabled album IDs from being easily scanned (as it just returns 404 now). Removed invalidatedAt property from stats cache. Instead their caches will immediately be nullified as they should (thus frees up memory slightly as well). Stats cache for albums will now only be cleared when truly necessary. As in, adding/removing files to/from albums will no longer clear them. Updated Nunjucks files to properly use h1, h2, h3 tags in actual hierarchical orders. Elements that don't need to use hX tags will now use P instead. Nothing changes visually, only structurally. Fixed some elements in Nunjucks using single quotes instead of double quotes. They'd have worked the same, but consistency. Added h1 title in FAQ page. Make text for no JS warning a bit bigger, and improved the phrasing a little bit.
2 years ago
<h1 class="title">
Frequently Asked Questions
</h1>
<hr>
Improved albums public page cache and more Removed its dependency towards albums' editedAt property. Editing album's metas (name, description, etc) will no longer update its editedAt property. Instead it will now ONLY be updated when adding/removing files to/from it. Just like how it was meant to be, which was to be used to check whether it's necessary to re-generate their downloadable ZIPs. Albums public page cache will still be properly invalidated when adding/removing files to/from it, as well as after editing their metas. Added views/album-notice.njk to be used to render okay-ish notice when an album's public page is still being generated. I was originally thinking of using it for disabled albums as well, but I refrained from it to reduce the possibility of disabled album IDs from being easily scanned (as it just returns 404 now). Removed invalidatedAt property from stats cache. Instead their caches will immediately be nullified as they should (thus frees up memory slightly as well). Stats cache for albums will now only be cleared when truly necessary. As in, adding/removing files to/from albums will no longer clear them. Updated Nunjucks files to properly use h1, h2, h3 tags in actual hierarchical orders. Elements that don't need to use hX tags will now use P instead. Nothing changes visually, only structurally. Fixed some elements in Nunjucks using single quotes instead of double quotes. They'd have worked the same, but consistency. Added h1 title in FAQ page. Make text for no JS warning a bit bigger, and improved the phrasing a little bit.
2 years ago
<h2 id="general" class='title is-spaced'>General</h2>
<h3 class="subtitle">What is {{ globals.name }}?</h3>
<article class="message">
<div class="message-body">
This is a fork of <a href="https://github.com/WeebDev/lolisafe" target="_blank" rel="noopener">lolisafe</a>.<br>
{{ globals.fork_host }} repository of the fork is located <a href="{{ globals.fork_repo }}" target="_blank" rel="noopener">here</a>.
</div>
</article>
{% if globals.enable_faq_banned_categories -%}
<h3 class="subtitle">Are there any <strong>banned categories</strong>?</h3>
<article class="message">
<div class="message-body">
Banned categories are the following, <i>but not limited to</i>:<br>
<strong>Child pornography.</strong><br>
Virus/malware, or anything Google Safe Search would categorize as <i>unwanted software</i> *.<br>
Copyrighted content. Meaning I will respond to copyright takedown notices,.. if any.<br>
<strong>Full-length episodes of cartoons, TV shows or movies of any kind.</strong> Japanese, Chinese, Antarcticaness, I don't care.<br>
CD drama audio files. I only know of Japanese shows that have these, but regardless of nationality.<br>
<br>
Any of such uploads, when found, will be purged immediately without any prior notice.<br>
Repeat offenders will have their IPs permanently blocked from accessing {{ globals.whole_faq }}.<br>
For child pornography specifically, first offenders will immediately be blocked permanently.<br>
<br>
* When Google Safe Search detects <i>unwanted software</i>, Chrome's users will be alerted that anything they download from {{ globals.whole_faq }} are <i>unsafe</i>.
</div>
</article>
{%- endif %}
<h3 class="subtitle">Will you keep my uploads forever?</h3>
<article class="message">
<div class="message-body">
Unless the uploads are included within the banned categories above, or some other bullshit, I will.<br>
{% if globals.takedowns_url -%}
In case I have to take down any uploads, I will log their names and explanations in <a href="{{ globals.takedowns_url }}" target="_blank">here</a>.<br>
{%- endif %}
<br>
Otherwise, we also have temporary uploads feature, with which you can have your uploads be automatically deleted after a period of time.<br>
It is disabled by default, but you can configure it through our homepage uploader's Config tab.
</div>
</article>
<h3 class="subtitle">How can I keep track of my uploads?</h3>
<article class="message">
<div class="message-body">
Simply create a user on the site and every uploads will be associated with your account, granting you access to your uploads through our Dashboard.<br>
You will <strong>have</strong> to do this if you ever want to delete your own uploads in the future, unless you choose to use the temporary uploads feature.
</div>
</article>
<h3 class="subtitle">What are albums?</h3>
<article class="message">
<div class="message-body">
Albums are a simple way of sorting/categorizing uploads together.<br>
You can share public links to these albums, allowing everyone else to view pretty listings of the uploads in them.<br>
Albums can also be downloaded as ZIP-archives.<br>
Both of these features can be toggled per-album basis from the Dashboard.
</div>
</article>
<h3 class="subtitle">Why should I use this?</h3>
<article class="message">
<div class="message-body">
I don't know.
</div>
</article>
<h3 class="subtitle">I saw something too illegal for my tastes here, what should I do?</h3>
<article class="message">
<div class="message-body">
Send a strongly worded email to <a href="mailto:{{ globals.email }}">{{ globals.email }}</a> and I will try to get back to you within <strong>48 hours</strong>.<br>
These include copyright takedown notices and reports about uploads violating banned categories.
</div>
</article>
{% if globals.support -%}
<h3 class="subtitle">How can I support {{ globals.name }}?</h3>
Updated Upgraded dependencies. Stop adding cache-control header to album zip files unless config.cacheControl is enabled. Updated CSS files. Moved thumbnail-related styling to thumbs.css. Various other fixes & improvements. Moved render.js from public/js to public/js/s. Removed sharex.js in favor of public/js/s/utils.js. Moved getPrettyDate() & getPrettyBytes() to that JS file as well. Added lsKeys global variable wherever applicable. Previously the idea was only used in dashboard.js. Added No-JS version of album public pages. You'll only have to add ?nojs to the URL. Viewing the regular version with JS disabled will show a notice with a link to the No-JS version of the particular album. Overall page size of the regular version will now be lower as well, since there'll be no need to add noscript tag for each thumbs. No longer show Administrator section to non-admin in the dashboard. Moderators will ONLY be able to see manage users menu as well. Simplified FAQ wherever applicable. Added a new FAQ about bug report or feature request. Updated link for Firefox extension. Also pushed Firefox link before Chrome, cause I like it more. Added browser settings menu to dashboard. This allows you to choose file size unit (kilobyte vs kibibyte) for that specific browser. The preference will be used on homepage, dashboard and album pages. This also allows you to set chunk size and maximum parallel uploads for the homepage uploader. All menu links in the dashboard will now scroll to the content once loaded. Previously it would only do so with manage uploads/users when switching pages. Refactored all instances of for-in & for-of loop from browser JS files. For the sake of uniformity, for now.
2 years ago
<article class="message">
<div class="message-body">
{{ globals.support | safe }}
</div>
</article>
{%- endif %}
</div>
</section>
<section class="section">
<div class="container has-text-left">
Improved albums public page cache and more Removed its dependency towards albums' editedAt property. Editing album's metas (name, description, etc) will no longer update its editedAt property. Instead it will now ONLY be updated when adding/removing files to/from it. Just like how it was meant to be, which was to be used to check whether it's necessary to re-generate their downloadable ZIPs. Albums public page cache will still be properly invalidated when adding/removing files to/from it, as well as after editing their metas. Added views/album-notice.njk to be used to render okay-ish notice when an album's public page is still being generated. I was originally thinking of using it for disabled albums as well, but I refrained from it to reduce the possibility of disabled album IDs from being easily scanned (as it just returns 404 now). Removed invalidatedAt property from stats cache. Instead their caches will immediately be nullified as they should (thus frees up memory slightly as well). Stats cache for albums will now only be cleared when truly necessary. As in, adding/removing files to/from albums will no longer clear them. Updated Nunjucks files to properly use h1, h2, h3 tags in actual hierarchical orders. Elements that don't need to use hX tags will now use P instead. Nothing changes visually, only structurally. Fixed some elements in Nunjucks using single quotes instead of double quotes. They'd have worked the same, but consistency. Added h1 title in FAQ page. Make text for no JS warning a bit bigger, and improved the phrasing a little bit.
2 years ago
<h2 id="technical" class='title is-spaced'>Technical</h2>
<h3 class="subtitle">What are the allowed extensions here?</h3>
<article class="message">
<div class="message-body">
{% if extensionsFilter.length -%}
{%- if extensionsFilterMode === 'whitelist' -%}
We only support the following extensions:
{%- else -%}
We support any file extensions, except the following:
{%- endif -%}<br>
{% set comma = joiner(' ') -%}
{%- for extension in extensionsFilter -%}
{{ comma() }}<code>{{ extension }}</code>
{%- endfor -%}
{%- else -%}
We support any file extensions.
{%- endif %}
</div>
</article>
<h3 class="subtitle">Why are my <strong>.htm/.html</strong> uploads being served as plain text?</h3>
<article class="message">
<div class="message-body">
There had been too many phishing pages being uploaded in the past.
Updated Upgraded dependencies. Stop adding cache-control header to album zip files unless config.cacheControl is enabled. Updated CSS files. Moved thumbnail-related styling to thumbs.css. Various other fixes & improvements. Moved render.js from public/js to public/js/s. Removed sharex.js in favor of public/js/s/utils.js. Moved getPrettyDate() & getPrettyBytes() to that JS file as well. Added lsKeys global variable wherever applicable. Previously the idea was only used in dashboard.js. Added No-JS version of album public pages. You'll only have to add ?nojs to the URL. Viewing the regular version with JS disabled will show a notice with a link to the No-JS version of the particular album. Overall page size of the regular version will now be lower as well, since there'll be no need to add noscript tag for each thumbs. No longer show Administrator section to non-admin in the dashboard. Moderators will ONLY be able to see manage users menu as well. Simplified FAQ wherever applicable. Added a new FAQ about bug report or feature request. Updated link for Firefox extension. Also pushed Firefox link before Chrome, cause I like it more. Added browser settings menu to dashboard. This allows you to choose file size unit (kilobyte vs kibibyte) for that specific browser. The preference will be used on homepage, dashboard and album pages. This also allows you to set chunk size and maximum parallel uploads for the homepage uploader. All menu links in the dashboard will now scroll to the content once loaded. Previously it would only do so with manage uploads/users when switching pages. Refactored all instances of for-in & for-of loop from browser JS files. For the sake of uniformity, for now.
2 years ago
</div>
</article>
{% if globals.server_location -%}
<h3 class="subtitle">Where is the server located?</h3>
<article class="message">
<div class="message-body">
{{ globals.server_location | safe }}.
{% if config.cloudflare.purgeCache -%}
<br>
We are using <a href="https://www.cloudflare.com/cdn/" target="_blank" rel="noopener">Cloudflare</a> though, so you can expect your uploads to be delivered quickly all over the world after they have been cached.
{%- endif %}
</div>
</article>
{%- endif %}
{% if config.cloudflare.purgeCache -%}
<h3 class="subtitle">Since my uploads are cached, what about after I delete them from the dashboard?</h3>
<article class="message">
<div class="message-body">
We will send API requests to Cloudflare to purge their cache immediately after you delete your uploads from the dashboard.<br>
Updated Upgraded dependencies. Stop adding cache-control header to album zip files unless config.cacheControl is enabled. Updated CSS files. Moved thumbnail-related styling to thumbs.css. Various other fixes & improvements. Moved render.js from public/js to public/js/s. Removed sharex.js in favor of public/js/s/utils.js. Moved getPrettyDate() & getPrettyBytes() to that JS file as well. Added lsKeys global variable wherever applicable. Previously the idea was only used in dashboard.js. Added No-JS version of album public pages. You'll only have to add ?nojs to the URL. Viewing the regular version with JS disabled will show a notice with a link to the No-JS version of the particular album. Overall page size of the regular version will now be lower as well, since there'll be no need to add noscript tag for each thumbs. No longer show Administrator section to non-admin in the dashboard. Moderators will ONLY be able to see manage users menu as well. Simplified FAQ wherever applicable. Added a new FAQ about bug report or feature request. Updated link for Firefox extension. Also pushed Firefox link before Chrome, cause I like it more. Added browser settings menu to dashboard. This allows you to choose file size unit (kilobyte vs kibibyte) for that specific browser. The preference will be used on homepage, dashboard and album pages. This also allows you to set chunk size and maximum parallel uploads for the homepage uploader. All menu links in the dashboard will now scroll to the content once loaded. Previously it would only do so with manage uploads/users when switching pages. Refactored all instances of for-in & for-of loop from browser JS files. For the sake of uniformity, for now.
2 years ago
Cache of their thumbnails will also be purged, if applicable.
</div>
</article>
{%- endif %}
{% if globals.enable_faq_tor -%}
<h3 class="subtitle">I cannot access this website with Tor and/or VPNs!?</h3>
<article class="message">
<div class="message-body">
My server is actively refreshing and blacklisting Tor exit nodes.<br>
There have been too many child pornography uploaders using Tor, that they simply didn't care about individual IPs being banned.<br>
Sometimes I might also end up blacklisting IP ranges that were known to come from VPNs, if there had been attempts with multiple of those IPs.<br>
Nothing much I can do about it. We live in a society.
</div>
</article>
{%- endif %}
<h3 class="subtitle">Are there any Desktop clients?</h3>
<article class="message">
<div class="message-body">
We do have some browser extensions:<br>
<a href="https://addons.mozilla.org/en-US/firefox/addon/lolisafe/" target="_blank" rel="noopener">Firefox extension</a>. Maintained by Bobby. Its GitHub repository is located <a href="https://github.com/BobbyWibowo/loli-safe-extension" target="_blank" rel="noopener">here</a>.<br>
<a href="https://chrome.google.com/webstore/detail/loli-safe-uploader/enkkmplljfjppcdaancckgilmgoiofnj" target="_blank" rel="noopener">Chrome extension</a>. Maintained by lolisafe's team. Its GitHub repository is located <a href="https://github.com/WeebDev/loli-safe-extension" target="_blank" rel="noopener">here</a>.<br>
With the Chrome extension specifically, you will have to manually set the domain in the extension's settings to <code>https://safe.rita.moe</code>.<br>
<br>
If you use Windows desktop, the safe support uploads from <a href="https://github.com/ShareX/ShareX" target="_blank" rel="noopener">ShareX</a>.<br>
You can download the config file by clicking on the ShareX icon on the homepage.<br>
When logged in, the config file will also be automatically populated with your account's token.<br>
This will allow you to manage your ShareX uploads from our Dashboard.<br>
<!--
<br>
If you use Linux desktop, there is a compatible bash uploader which I also maintain.<br>
You can learn more about it from <a href="https://github.com/BobbyWibowo/uguush" target="_blank" rel="noopener">its GitHub repository</a>.
-->
</div>
</article>
<h3 class="subtitle">Do you have a No-JS uploader form?</h3>
<article class="message">
<div class="message-body">
<a href="nojs" target="_blank"><strong>Yes!</strong></a>
</div>
</article>
{% if noJsMaxSizeInt and chunkSizeInt -%}
<h3 class="subtitle">Why is the maximum file size in the No-JS uploader form smaller?</h3>
Updated Upgraded dependencies. Stop adding cache-control header to album zip files unless config.cacheControl is enabled. Updated CSS files. Moved thumbnail-related styling to thumbs.css. Various other fixes & improvements. Moved render.js from public/js to public/js/s. Removed sharex.js in favor of public/js/s/utils.js. Moved getPrettyDate() & getPrettyBytes() to that JS file as well. Added lsKeys global variable wherever applicable. Previously the idea was only used in dashboard.js. Added No-JS version of album public pages. You'll only have to add ?nojs to the URL. Viewing the regular version with JS disabled will show a notice with a link to the No-JS version of the particular album. Overall page size of the regular version will now be lower as well, since there'll be no need to add noscript tag for each thumbs. No longer show Administrator section to non-admin in the dashboard. Moderators will ONLY be able to see manage users menu as well. Simplified FAQ wherever applicable. Added a new FAQ about bug report or feature request. Updated link for Firefox extension. Also pushed Firefox link before Chrome, cause I like it more. Added browser settings menu to dashboard. This allows you to choose file size unit (kilobyte vs kibibyte) for that specific browser. The preference will be used on homepage, dashboard and album pages. This also allows you to set chunk size and maximum parallel uploads for the homepage uploader. All menu links in the dashboard will now scroll to the content once loaded. Previously it would only do so with manage uploads/users when switching pages. Refactored all instances of for-in & for-of loop from browser JS files. For the sake of uniformity, for now.
2 years ago
<article class="message">
<div class="message-body">
This site is using Cloudflare, which limits the maximum upload size.<br>
Since the homepage uploader chunks your uploads through JS wizardry, it is possible to increase the maximum file size there.
Updated Upgraded dependencies. Stop adding cache-control header to album zip files unless config.cacheControl is enabled. Updated CSS files. Moved thumbnail-related styling to thumbs.css. Various other fixes & improvements. Moved render.js from public/js to public/js/s. Removed sharex.js in favor of public/js/s/utils.js. Moved getPrettyDate() & getPrettyBytes() to that JS file as well. Added lsKeys global variable wherever applicable. Previously the idea was only used in dashboard.js. Added No-JS version of album public pages. You'll only have to add ?nojs to the URL. Viewing the regular version with JS disabled will show a notice with a link to the No-JS version of the particular album. Overall page size of the regular version will now be lower as well, since there'll be no need to add noscript tag for each thumbs. No longer show Administrator section to non-admin in the dashboard. Moderators will ONLY be able to see manage users menu as well. Simplified FAQ wherever applicable. Added a new FAQ about bug report or feature request. Updated link for Firefox extension. Also pushed Firefox link before Chrome, cause I like it more. Added browser settings menu to dashboard. This allows you to choose file size unit (kilobyte vs kibibyte) for that specific browser. The preference will be used on homepage, dashboard and album pages. This also allows you to set chunk size and maximum parallel uploads for the homepage uploader. All menu links in the dashboard will now scroll to the content once loaded. Previously it would only do so with manage uploads/users when switching pages. Refactored all instances of for-in & for-of loop from browser JS files. For the sake of uniformity, for now.
2 years ago
</div>
</article>
{%- endif %}
{% if chunkSizeInt -%}
<h3 class="subtitle">So your API supports chunked uploads?</h3>
<article class="message">
<div class="message-body">
<strong>Yes.</strong> The homepage uploader was coded to chunk uploads into {{ chunkSizeInt }} MB pieces by default. However, this is configurable through its Config tab.<br>
2 years ago
<br>
If you want to chunk your API uploads, feel free to inspect the source code to see how it works.<br>
A rough description of how it works is to simply upload the chunks with their UUID information attached,<br>
and then call the "finish chunks" API with the said UUID, to rebuild them into a single proper file.
</div>
</article>
{%- endif %}
{% if globals.fork_repo -%}
<h3 class="subtitle">I found a bug! -or- I want to request a feature!</h3>
<article class="message">
<div class="message-body">
Feel free to create a {{ globals.fork_host }} issue <a href="{{ globals.fork_issues }}" target="_blank" rel="noopener">here</a>.</br>
If you do not have a {{ globals.fork_host }} account, you can also email <a href="mailto:{{ globals.email }}">{{ globals.email }}</a>.
</div>
</article>
{%- endif %}
<h3 class="subtitle">How do I delete my own account <strong>and</strong> all the uploads associated with it?</h3>
<article class="message">
<div class="message-body">
For now, you will also have to contact me through my email above.<br>
A feature to delete your own account by yourself is still <strong>work in progress</strong>.<br>
Otherwise, if you do not mind a record of your username being left here, it should be easy to bulk delete all your uploads from the Dashboard anyway.
</div>
</article>
</div>
</section>
<section class="section has-extra-bottom-padding">
<div class="container has-text-left">
Improved albums public page cache and more Removed its dependency towards albums' editedAt property. Editing album's metas (name, description, etc) will no longer update its editedAt property. Instead it will now ONLY be updated when adding/removing files to/from it. Just like how it was meant to be, which was to be used to check whether it's necessary to re-generate their downloadable ZIPs. Albums public page cache will still be properly invalidated when adding/removing files to/from it, as well as after editing their metas. Added views/album-notice.njk to be used to render okay-ish notice when an album's public page is still being generated. I was originally thinking of using it for disabled albums as well, but I refrained from it to reduce the possibility of disabled album IDs from being easily scanned (as it just returns 404 now). Removed invalidatedAt property from stats cache. Instead their caches will immediately be nullified as they should (thus frees up memory slightly as well). Stats cache for albums will now only be cleared when truly necessary. As in, adding/removing files to/from albums will no longer clear them. Updated Nunjucks files to properly use h1, h2, h3 tags in actual hierarchical orders. Elements that don't need to use hX tags will now use P instead. Nothing changes visually, only structurally. Fixed some elements in Nunjucks using single quotes instead of double quotes. They'd have worked the same, but consistency. Added h1 title in FAQ page. Make text for no JS warning a bit bigger, and improved the phrasing a little bit.
2 years ago
<h2 id="privacy" class='title is-spaced'>Privacy</h2>
<h3 class="subtitle">What information is kept with uploads?</h3>
<article class="message">
<div class="message-body">
The uploader's <strong>IP address</strong>.
</div>
</article>
<h3 class="subtitle">What information is kept with users?</h3>
<article class="message">
<div class="message-body">
Technically, <strong>none</strong>.<br>
After all, not even an email address is required to register an account.<br>
Anything will do as your usernames, and passwords are also encrypted.<br>
If a registered user has not uploaded anything even once, then I will not even be able to associate it to any specific IP address.
</div>
</article>
<h3 class="subtitle">Why do you need to keep my IP address?</h3>
<article class="message">
<div class="message-body">
<strong>Security purposes.</strong><br>
For instance, if it is necessary to purge uploads from a specific IP address due to abuse, it <i>will</i> help a lot to be able to find all uploads by that specific uploader.<br>
My safe have been plagued by aplenty of abuse, so this policy will remain as long as the safe lives on.
</div>
</article>
<h3 class="subtitle">Does the server have some sort of access logs?</h3>
<article class="message">
<div class="message-body">
<strong>Yes.</strong><br>
The logs contain each visitor's IP address.<br>
This is required by our automated system, that checks logs in real time to detect and punish abuse, such as DDoS attempts, scanners, and so on.<br>
Logs are rotated daily, and the server will only keep the last 10 logs.<br>
Manage albums admin page, and more! Resolves #194. Added pagination for Manage your albums page. Albums sidebar will now only list 9 albums at most. Use Manage your albums page to view the rest. Albums in the list will now have View uploads button after all. Delete album button for albums renamed to Disable album. Since techincally the server would've always been disabling the albums instead of deleting them. It was something upstream dev's decided, and I haven't bothered changing its behavior. I'll work on actual Delete album feature some other days. As the title says, added Manage albums admin page. Viewing uploads of an album will hook into albumid: filter key. I'll work on filter and bulk operations some other days. Updated styling for disabled albums and users. Instead of havine a line through them, they will be greyed out. Disable public page of albums will still use line through however. Links to album's disabled public page are now clickable. Added a new button styling is-dangerish. It'll be orange. Renamed /api/albums/delete to /api/albums/disable. For backwards compatibility, /api/albums/delete will still work but automatically re-routed to /api/albums/disable. /api/uploads/list will no longer print SQLite errors for moderators or higher when encountering them. It was originally used to inform moderators of non-existing colum names when used for sorting. But on one of the recent commits, I had added a check for allowed colum names. Improved some caching in dashboard page. Added new entries to cookie policy. Some other small things. Bumped v1 version string and rebuilt client assets.
2 years ago
So you can be assured that the logs will only be kept for <strong>10 days at most</strong>.
</div>
</article>
{% if config.cookiePolicy -%}
<h3 class="subtitle">Cookies</h3>
<article class="message">
<div class="message-body">
We use cookies to offer you a better browsing experience and to analyze our traffic.<br>
You consent to our cookies if you continue to use this website.<br>
Details in our <a href="cookiepolicy">Cookie Policy</a>.
</div>
</article>
{%- endif %}
<h3 class="subtitle">I still have more unanswered questions!</h3>
<article class="message">
<div class="message-body">
Feel free to email <a href="mailto:{{ globals.email }}">{{ globals.email }}</a>.
</div>
</article>
</div>
</section>
{% include "_partial/floating-home.njk" %}
{% endblock %}