I spoke before about one of my forums not needing to be high security (as it has no sensitive information) and only has infrequent visitors. Password resets are a frequently requested issue.
Ive made a widget with a puzzle to solve which is generated from a hash of the email. The user is shown the solution to this puzzle each time they login, and its easy to remember. So any time they cant login they probably will remember the solution.
The widget is on a public category in the forum viewable by guests, so a person can enter their username, and complete the puzzle.
Is there an API call which can be called with Admin permissions, which will reset a password, just using the username of the user?
The step1 Get request doesnt seem to take a username or UID number as a payload?
So how would this API request theoretically work, if it doesnt know which user you are asking for a reset code for?
Its been a while since I tried getting the email working (which sends out confirmation links, password resets etc)
So I retried ...
put in my Zoho email and its password in the Admin - settings - email, but nothing gets sent out. Ive put an ecample email in for this screenshot
Is there something else I need to do Zoho end to let Nodebb send emails? 1000018854.jpg
Sorry but this is where I am confused. If I used a hotmail, or gmail even instead, do I need to reach out to their support too?
Can you just say a little more on what DKIM and SPF are?
@pitaj
Yes I tried sending a test 'Welcome email'
The banner came up email sent
No email arrived, and I logged into the Zoho emai account and nothing was in sent folder.
Do I need to set IMAP up on Zoho so nodebb can email from it?
There was nothing in output log, except this Warning which appears unrelated
WARNING: The keyword 'none' must be used as a single argument.
../../../bootstrap/scss/mixins/_box-shadow.scss 10:9 box-shadow()
../../../bootstrap/scss/forms/_form-control.scss 40:7 @import
bootstrap/scss/_forms.scss 3:9 @import
- 19:9 root stylesheet
@pitaj ok, thanks
Just out of curiousity, why should the body content of the email make any difference to the chance of 'it failing silently'?
Whether its a Welcome, banning, or digest email for example? How does what is written in the text of the email, make any difference to chance of it getting sent?
For a lot of things in ActivityPub, there are almost direct parallels in NodeBB. An as:Note object pairs well with a NodeBB post, an as:Person is a NodeBB user, etc.
One thing that didn't map 1:1 was the Delete activity, which at surface level, seems rather straightforward — just delete the object! However, once you dig in, there are some additional considerations:
in NodeBB, we have two separate states for content removal.
A delete, where the post is still present (but its content unavailable to non-privileged users), and a
A purge, where the post is scrubbed from the database entirely, and all references to it, removed
in ActivityPub, there is a single activity, as:Delete
Implementors may opt to replace the object representation with an as:Tombstone (how quaint!), but they may also just opt to use a 404
So there are some nuances that are left intentionally vague.
This is how NodeBB will interpret the protocol specification, and how we will align it with our own dual-state post deletion mechanic (delete & purge):
When a local post is deleted, we will federate out an Update(Tombstone) referencing the id
Afterwards, if the content is retrieved, an as:Tombstone will be served.
Deleted posts in NodeBB still maintain their place in the topic, so when the context is retrieved, the note will still be present in the collection.
If we receive an Update(Tombstone), we will delete the local representation of the post
When a local post is purged, we will federate out a Delete(Note)
Afterwards, if the content is retrieved, we will serve a 404
The note will no longer exist in the context collection
If we receive a Delete(Note) (or Article, or Question, etc.) we will not delete it immediately. Instead, as kaniini advises, we will attempt to retrieve the object from the origin:
If we see an as:Tombstone, we will delete the post (soft delete)
If we encounter a 404 or 410, we will purge the post (hard delete)
I'm writing this out less as a guideline for myself, but to solicit opinions and to give others a chance to point out if I've interpreted the spec incorrectly.
Just my thought, but the whole Delete then Purge has always irritated me.
Delete should just be Delete.
If a Mod wants to temporarily hide something they could move post, or delete and keep a copy.
The only thing Delete then Purge does is add extra step to removing something!
Maybe a basic question, but Im not sure, until theres a pre-release of Nodebb v4 (which I cant wait for!)
But will my forum fediverse account be enough for an all in one solution, so I wont necessarily need my Mastodon account too?
The reason Im asking is because, at times, ideal Mastodon hosts can be hard to find. I ran my own instance for a while, and many signed up - it was bursting at capacity before long 🙂
So will a Nodebb v4 forum account be complete enough to be a full fediverse solution for those who use Mastodon etc.
Can I log into the fediverse mobile apps etc?
I tried logging into a couple I have on my android phone but it didnt work.
Not sure what my nodebb fed password is, (is it mirrored from my main account) or how to reset it? 1000016862.jpg
@vwbusguy said in Unsuspecting people:Me: I wonder if I can have a causal conversation about something that's been bugging me lately about CFS in the #Linux kernel with anyone here.:
I'd like your thoughts on if CFS can be completely fair if its behavior depends so much on the version and distribution of the kernel. Let's compare Google's current cOS vs SLES 15SP5, for example.
cOS prioritizes containerized workloads, ensuring they get more CPU time compared to other processes running on the system. This aligns with Google's focus on containerized applications in cloud environments.
So the rulebook of whats most fair is almost like a George Orwell quote,
all processes are equal, but some are more equal than others!
