lionleaf / lionleaf/dwitter

Error display let's you get outside the iframe and affect the main site

Open
#373 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

contributions welcome dweet-breaking good first issue security
Dominant language
JavaScript
Stars
803
Forks
68
PR merge metrics
No merged PRs in 30d

Description

While I'm on the security side; it is possible to post dweets that, while maybe not a real security threat, can really affect the flow of the website by throwing exceptions with interesting strings. For instance hundreds of newlines.

One way to solve it is to deal with those specific instances, ie. don't allow it to grow with newlines etc.

But I suggest we simply disable the viewing of errors when you are not editing the code. Now this breaks some old dweets that relied on `throw "text"` as a cheap way to print text, but there aren't too many of them. How do people (especially authors of such dweets) feel about this change? As far as I have seen, most of those dweets are fun small ones; not big efforts with hours of golfing (but I could be wrong).

You'd still be able to show of clever `throw` tricks, you would just have to have the users edit the dweet first.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points. Reproduce the reported behavior with a dweet that throws a long string, especially many newlines, then trace how errors are displayed outside code-editing mode. Done should prevent error output from affecting the main site while preserving the intended editing workflow.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
frontend, security, web-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.