@mfikes: Thanks, will do

@xcthulhu: JS, and particularly the browser environment, is hackable enough so that as soon as untrusted code enters your VM, say goodbye to security

@xcthulhu: any sort of js injection is bad not restricted to cljsjs, you should look into the Content-Security-Policy http headers if you really want to lock things down

in my experience the biggest issue however are plugins the user already have installed

nothing related to your own code or server can help there

@xcthulhu: In which way is modifying React specifically related to cljs? The generated javascript is just javascript when it reaches the browser. So I suppose the cljs compiler could potentially open up an additional security hole, but I fail to see how it currently does that?

@grav: Well, the idea is that an easy attack vector is modifying window.React.

@thheller: Avoiding globals like window.React or window.crypto is a measure you can take but it looks like nobody bothers much.

@xcthulhu: how is that a factor? if someone can execute code on your page they can do anything, they don't React for that?

most likely they will read cookies and such

React does not open any new risks that aren't there without

It depends on the app; you might not store anything of value in cookies, and just make the user enter a password via a form.

then they can just replace whatever method you are using to send it to the server

only way to be secure is ssl + no outside scripts

I'm not, I'm trying to use ECDH to avoid sending it.

Content-Security-Policy helps too

For sure, but I seriously have crazy clients that ask me to handle digital currency in the browser. I told the last client "No" but I've been racking my brain on how to do this.

well for anything secure outside scripts are a no-no

I can lock down most stuff by just doing doing authentication via ECDSA and encrypted commumication with ECDH for shared secrets

that doesn't do anything

Oh?

as soon as someone is executing code in your context

the needed information will leak

you cannot allow outside scripts ever

+ enforce ssl

even better with HSTS

but you said compromised ad server

You would still not want to hand the server your password for your digital currency because the server can get hacked too.

as soon as an ad is on your page you are basically giving up any and all security

But I guess when it comes to trying to tighten up injection attacks against React or window.crypto nobody seems to worry

Or they do, but half-heartedly

personally I wouldn't worry about any of that

make sure all communication between you and the server is over https

+ no outside scripts

+ Content-Security-Policy

doesn't get safer than that IMHO

Okay, so my last client wanted to make a "Decentalized Facebook" where you can tip your friends with digital currency

In that case, you would have to talk P2P via WebRTC

Like I said, I told them "No" but a lot of these security measures assume a trusted central entity...

Content delivery is another problem for that platform...

well building something like that in the browser is probably never be secure enough

All I did was server side crypto for them

but you always need something to deliver the app.js

I suggested IPFS

Are you familiar with it?

no, read some docs once but nothing past that

Basically it associates files with a merkle-hash, similar to commits in git.

So the idea would be that you could go to or something

that does not look like something a browser can go to?

Yeah, obviously you would need to ask users to download a plugin.

Maybe Brave will have support in a few years.

well anyways, in the context of http and clojurescript (or js) use https + no outside scripts + Content-Security-Policy for the paranoid

Sure

I still would prefer if React wasn't a global object but I guess nobody else seems to care.

I do not see why that is an issue?

if you can trust the code there is no problem

if you can't you can't, all the "hacker" would need is to open a dev console and look up the name it is using instead

that is not a hard hack

obfuscation is not security

Why couldn't you keep it in a closure so they couldn't touch it?

That would be nice

uhm that would be simple

although I have no idea if react can work with that

It's not bullet proof

in cljs you have :output-wrapper

but still, nothing is gained in terms of security

Yeah.

thanks for your time @thheller

ClojureScript 1.9.211 released https://groups.google.com/d/msg/clojurescript/KIX2ll89Ohk/3DJWEGk6DAAJ

Clojurescript seems to have a new website http://clojurescript.org/

this no longer redirects to the GitHub repo

also open source: https://github.com/clojure/clojurescript-site

http://blog.cognitect.com/blog/2016/8/15/welcome-clojurescript-org

Now that’s awesome!!!

@alexmiller: I somewhat understand that you’d want the paragraph

Why Clojure?

Clojure is a dynamic, general-purpose programming language supporting interactive development. Clojure is a functional programming language featuring a rich set of immutable, persistent data structures. As a dialect of Lisp, it has a code-as-data philosophy and a powerful macro system.

on the first page of http://clojurescript.org

it’s really explaining the first para, so I don’t think ClojureScript would make sense there

ClojureScript is a Clojure dialect

but I understand that it may be a little weird seeing that at the top of the cljs site

will think about it

I’m also sort of uneasy about ‘Clojurescript is a compiler for Clojure that targets javascript’. It is most probably correct, but to me, a user, Clojurescript is a dialect of Clojure that runs in the browser (or anywhere else you can run Javascript)

I appreciate that this is hard to write in a way which doesn’t confuses the simple likes of me, and I have no clue about how to write it clearer while still keeping it concise and correct.

every release David does has the first line "ClojureScript, the Clojure compiler that emits JavaScript source code."

lol, and I tend to read most of them 🙂 It’s not easy writing for the internets.

I guess I’m just complecting language and compiler.

Anyways, thanks for the site and the great work!

Congrats on the new site!

@alexmiller: this is great, but one small annoyance: "Using ClojureScript on a Web Page" begins with an error "You will not see "Hello world!" but instead you will likely see an error like the following:" which I think will put newbies off 3:02 it would be better to show them how to do it right, then point them to common errors and how to fix them afterwards

all content was copied over from the ClojureScript wiki page and there are many that probably need updating

i.e. don't start with a negative because we want to encourage people

please file an issue or better, a PR !

ok sure

https://github.com/clojure/clojurescript-site/issues

if you’re submitting a PR, you will also need to sign the Contributors Agreement - see http://clojurescript.org/community/contributing_site

I want to load some EDN data to configure my re-agent app at runtime. As far as I can see there’s nothing built-in to CLJS to do this (no slurp for example) so I need to find a CLJS HTTP client and make a request. Is that right?

@sandbags: goog.net.XhrIo is a thing, you don’t need anything else

if for some reason you want something that appears more idiomatic sure 3rd party library - but Google Closure is just fine for this

Thanks @dnolen I guess a thin wrapper over Closure would be nice, if not I’ll use it direct. thanks for the pointer.

"The engines, in the large, are specifically oriented towards JavaScript semantics and execution, i.e. they are not as general as the JVM and CLR." O, RLY? With JS your performance will fall into a huge hole as soon as you use dynamic nature of the JS language

@dnolen: what’s the status of Spec parity with Clojure as of the latest release?

@anmonteiro: at parity with the caveat that cljs.spec.test is a bunch of macros instead of fns

which I don’t think really matters much in actual usage

@dnolen: clojure.spec/assert is not portable then, is it?

@anmonteiro: oh right I might have missed assert actually

somebody can submit a patch for that 😉

heh… i noticed that this morning and assumed it was deliberate 🙂

I encourage everyone to kick the cljs.spec tires that are there - the sooner issues get flushed out the better

Is there any standard practice for how to instrument a cljs app only during development? I'm imagining conditionally calling instrument if it's running without optimizations but not sure how to determine that.

@sekao: there isn’t but I can certainly imagine a number of ways to do it - either via custom builds (like test builds) or some component like approach

please add forum on https://www.discourse.org/

I was looking at the cljs JIRA and one of the latest issues is http://dev.clojure.org/jira/browse/CLJS-1710, which talks about how there is no double-in in cljs spec. which I thought was because all numbers are doubles and thus double-in doesn’t make sense. I checked the source and I noticed there is an int-in though, which I thought was weird, why is this?

or rather, what’s an int in cljs?

nevermind, a goog.math.Integer or a goog.math.Long. now to go figure out what those are...

@chris some things are tied to clojure.test.check and the provided generators

@dnolen or anyone interested in instrumenting only during dev: it looks like with boot-cljs you just need a separate dev-resources and prod-resources that contain separate main.cljs.edn files. that config lets you specify :init-fns, so the dev one can just include a call to cljs.spec.test/instrument. seems to work!

@sekao: nice

@chris: Be careful with goog.math.Integer, multiplication is currently broken upstream and pending a patch: https://github.com/google/closure-library/pull/741

anyone experiencing an error when instrumenting a multi-arity function? i saw that it was reported already but it is marked as resolved. i’m getting the same error in 1.9.211: http://dev.clojure.org/jira/browse/CLJS-1663

“same error” is not particularly useful information 🙂

show a complete, independent failing example - thanks

bbiab

@dnolen: np, i made a gist with more specifics: https://gist.github.com/oakes/82c8b254fa2c4fecbc85d50b94d91d9a

i’m happy to file an issue on jira, i just hesitated since i saw there already is one that is closed

Alt is not right you want cat

Oh hrm ok will take a look in a bit

Sorry on phone

@sekao definitely a regression, fixed and cutting a release now

ok thanks!

@sekao: 1.9.216 released

@anmonteiro: includes assert ^

👍

is there a good way to kinda turn on a global flag? e.g. (def ^:dynamic *profile* nil) … I know I can binding it … but if I just wanted to make it true for awhile 🙂

set!

(also this is amazing: http://cljs.github.io/api/)

@jr: :thumbsup:

There are also :closure-defines but that's compiler settings so you need to restart compiler for changes

@sandbags: i’ve been using https://github.com/r0man/cljs-http quite successfully, returns a core.async channel to work with

intermittently I’m unable to call prn while js/console.log continues to work. I am using (enable-console-print!). Any guesses?

@rorydouglas: thanks for the pointer, sounds good

nvm. this is the issue https://github.com/adzerk-oss/boot-cljs/issues/126

@uwo: As a workaround I suggest using cljs-devtools + js/console.log

@juhoteperi: yeah, cljs-devtools is pretty cool!

@uwo: Btw. what version of boot-cljs-repl do you have (if any?)

@juhoteperi: "0.3.2"

@uwo: Could you try 0.3.3, it is possible that the cause is that piggieback by default redirects all output to REPL instead of console, 0.3.3 overwrites this default.

@juhoteperi: it took me a moment to ensure that I was using 0.3.3. It doesn’t appear to fix the issue

not sure if everyone is familiar with “namespaced maps”, but it is a new syntax that was added this week to cljs

i’m trying to keep a clear and comprehensive syntax reference here: http://cljs.github.io/api/syntax/

A quick search for how to use clojure libraries (specifically datomic-backed libs) with clojurescript didn’t turn up anything definitive. Anybody have advice?

(Currently I have routing and other api-esk libs running via nginx-clojure that serves templated pages which wraps the datomic queries and I would like to include my reagent stuff so I can serve all the content from the same place and re-use the datomic libs which are in a clojure namespace)

This is the closest I came but its from March 2014 https://8thlight.com/blog/andrew-zures/2014/03/08/combining-clj-and-cljs-libraries.html

Oh. I’m using Boot although Lein advice is cool, thanks!

@georgek: there is https://danielcompton.net/2015/06/10/clojure-reader-conditionals-by-example

Great! Thanks for the lighting-quick response. I’ll check it out!

Can you explain what you’re trying to do a little further? Not quite sure I understand

Sure,to start with I’m planning on using nginx-clojure for everything. I’ve written a set of api’s that deal with application logic in general and have written a few nginx handlers to serve up templated pages that are backed by a aws ddb datomic store. Since most of the app really is going to be in reagent I’m looking for a way to re-use my internal api libs (that currently are clojure/datomic) in the clojurescript part

Not sure its really relevant that I’ve specified handlers and routes for the handful of templated pages since the api’s I want to use are underneath them

Cool, one way to do this is to have src/clj, src/cljc, and src/cljs directories for each type of file

And write your cross platform code in cljc files

well that sounds elegant

Not quite sure how that will work with datomic stuff though