Hackpads are smart collaborative documents. .


1203 days ago
Unfiled. Edited by Mitar , emgee 1203 days ago
  • Hm, I just now came to this and I am a bit confused. You are mixing two types of attacks here. Passive attack (attacker can just see the traffic) and active attack (attacker can inject/server any traffic they want). With new SHA256 method, attacker can as a passive attack sniff the traffic and then impersonate the user. While (if I understand correctly) with SRP they were not able to do that, because password did not leave the client side at all. And even if they captured login tokens, you can cycle them regularly and expire the old ones, while not requiring for the user to change the password. Yes, to protect against an active attack you need SSL, but SRP was protecting against the passive attack as well. Now, this is not true anymore?
  • In addition, you are sending now passwords over the wire as unsalted SHA256, so passive attacker can use rainbow tables to reconstruct user's password (OK, a bit hard for SHA256, but then there is a reason why you are using bcrypt on the server and not just SHA256) which user might be reusing at another site and thus gain access to that site as well.
  • Mitar, I think the idea is if you're not using SSL, a passive (sniffing) attacker would be able to get the auth token, regardless of Meteor's use of SRP. With SRP, the benefit is the password isn't sent over the wire, but an attacker gaining access to the database can quickly discover the passwords through brute force. With bcrypt, the benefit is computationally, it's prohibitively expensive to discover the passwords even with a dump of the database. The downside to bcrypt is that the password sent over the wire in (effectively, though not technically) plaintext. Using SSL mitigates this downside, however, and you retain protection against brute force if (seems like when, these days) an attacker gains access to the database. As in all things in life, there are tradeoffs, but with the SSL caveat, this seems like the move to bcrypt is better overall. I just pretend to be an expert on this sort of thing, so you can take this with a grain of salt, but I think this was the thinking that took place for this decision.
  • Yes, but auth token can be regularly cycled with SRP, making it less useful. In addition, intercepting the token does not help you obtaining the password, while intercepting a SHA256 of the password might help you there. And one cannot cycle the SHA256 of the password without asking the user to change the password.
  • One could probably also plug bcrypt into SRP as a hash function.
  • When a user registers, we hash the password with SHA256 on the client and send it to the server in the `createUser` method (as `options.hashedPassword`). Before inserting the user document, the server generates a salt using the `bcrypt` NPM module's `genSalt` method and then bcrypts the `hashedPassword` with the salt. The bcrypted password should be stored in the user record under `user.services.password.bcrypt`.
974 days ago
Unfiled. Edited by Sang Yoo Kim , Mitar 974 days ago
The Blaze rendering engine and the Spacebars templating language have been great for most Meteor users. They allow people with little experience in web development get started quickly with intuitive primitives and syntax. However, it's difficult to build modular and reusable code in the current system for a few reasons. I believe that some small changes in syntax and API can result in significant improvements while keeping the spirit of Blaze intact. fdsjdsjkfdajfkdsa fdajfkdjakfdjsk fjskfjdskafdjskafdjskafadfas
Richard L
  • After seeing Mitar's Blaze Component package, this makes much more sense, but it does look like a huge refactor.
  • Yes, in Blaze Components `this` is almost a template instance (component instance).
605 days ago
Unfiled. Edited by Mitar 605 days ago
  • Wrapper packages with Meteor features (decouple, depend on Meteor npm packages)
  • Those are packages wrapping existing packages, but with for example Fibers-enabled API instead of callback-style API?
979 days ago
Unfiled. Edited by Slava Kim , Mitar , steph1210 979 days ago
  • If I understand correctly, data context stays unchanged, only resolving of variables inside a template finds them insde `args`?
Slava K
  • No, @args is not related to the data context at all. With this proposal, hopefully, data context is not used anywhere at all. @args is just a dynamic way to get all passed arguments, no matter if they are declared or not (similar `arguments` keyword in JavaScript). 
  • Yes, but one can still access the data context, if you want?
  • I think this is the same reasoning why initially there was no paranthesis in helper arguments. And then you couldn't do everything. And now we have them. I think this will be the same limitation. So my main concern here is that using arguments for populating the lexical scope is just one use of them. You might want to pass arguments which then are not available in the template, but are something helpers use to guide their behavior. I do not know, but sometimes it is simply hard to get to imagine names for variables and type them just so that you then pass them to a function which does take only positonal arguments anyway.
Slava K
  • I think the parenthesis are important and they were not present from the start because of the design conflict between JS-expressions and nested handlebars expressions.
  • As for arguments: I really think you can do everything with keyword arguments what you could do with the positional arguments. Just having positional arguments can be limiting once the number of args is getting big. Having both options at the same time is often confusing and creates multiple styles to do the same thing. With positional arguments, the implementation of optional and default args also makes things more complicated compared to just keyword.
  • I agree that keyword arguments are more powerful and if we want only one, then we should have that. But positional arguments are also very useful when you do not have a reasonable name for a variable. Imagine a template which wants to get a list of colors to iterate over for rows. You would do `{{@>colors 'red' 'blue'}}`, or would you prefer to do `{{@>colors color1='red' color2='blue'}}`? If you are not going with positional arguments, then I suggest you provide a way to specify both arrays and objects. So that one could do `{{@>colors colors=['red', 'blue']}}` or `{{@>colors colors=[{name: 'red', hue: '#ff000'}, ...]}}`
  • In other sense, `new Blaze.Template` should allow you to specify that argument list somehow. Same as it now allows specifying the content function.
Slava K
  • If your are using templates from 3rd party, it is likely that your templates will not work if you suddenly switch them to lexical scope from data context. They are different and they do have different behavior. This is exactly why, the opt-in is determined by template and not by the helpers/additional JS code. Compiled templates opt-in by having extra options passed to the `new Template`.
  • Currently, based on the code, there is no difference between "opt-in" and having empty list of arguments? I think that is OK if this means that you can still call `{{@> template}}` on a non-opt-in templates and all it happens is that it gets arguments into `.args` and data context and the rest still works?
  • I would like to pitch one more idea here. :-) Can those arguments be passed to the template lookup method. Because currently one can access current data context when resolving the template, but there should also be a way to access passed arguments. Just so that you can use that for some custom things like we are doing in Blaze Components.
Slava K
  • Can you drive your proposal by a concrete example with a code sample?
  • See the link above? So currently the main ugly part of the Blaze Components is that I have to mingle with data context to get arguments to pass to the class constructor . And I do that when called from Blaze._getTemplate , So if I could access arguments when looking up the template, then I could simply pass that in as component constructor arguments (this is also one reason why position arguments would be helpful, so that I can do the same as helper arguments receive them).
  • I have a general question here. Why introducing one more thing (scope), what is wrong with template instance? Why are simply arguments not attached as properties to the template instance? So if you have `args="foo bar"` and I do `{{> template foo='a' bar='b'}}` then in the template instance I get two reactive vars attached to `templateInstance.foo` and `templateInstance.bar`? If ReactiveVars would be implemented without `.get`, the same way as meteor-variable  was (so no `.get`, you just called the variable as a function), then you could already access `{{foo}}` in the template an get access to `templateInstance.foo`as a reactive value?
Slava K
  • Attaching random variables to the template instances is not a good API. This is not a good place for this, it can conflict with internal properties of template instances, there are other problems with this being ad-hoc. A better way is to create a special standard place for these variables. This is covered in the "local template state" proposal in a different PR:meteor/meteor#3561
  • Local state is important for components to keep the internal state. Arguments are important for composing templates and reuse them passing different configurations. Eventually, there should be a simple way to initialize the local state based on the arguments, too.
  • They are not random variables. They are only those specified in `args`. You could even check that they do not match any of internal (reserved) ones and warn the developer. And it is the developer who knows which variables they put into `args` and thus which variables are added to the instance template. It would be just a simpler way to assign values to template instance. Now you can do it in `onCreated` and is even documented that you can do it. Then you could do it directly through the template, but with a check. So template developer can offer few template instance spaces to the template user and they know exactly which ones are offered. So they know that they are not "random".
Slava K
  • Template arguments for composition, and the local state are different things solving different problems. I don't see any good reason to mix them up.
  • I think there is a good reason: simplicity of the API and the doc. One "scope" is better than three. Maybe there are good reasons to prefer three "scopes", but please be careful on this. You are talking about "composition" and "local state", so it seems you have concepts in mind. The question is: will those concepts will easily be explained in the Meteor doc? Wouldn't it be enough if I promised to prefix my variables with `composition_` and `localstate_` ? :-)
958 days ago
Unfiled. Edited by Mitar 958 days ago
Ben N
  •  This seems viable if developers have to opt into it explicitly. Enforcing immutability without developer cooperation seems like a hard problem.
1470 days ago
Unfiled. Edited by Mitar 1470 days ago
  1. Mitar Milutinovic - PeerLibrary - what is new and what we had to solve to get there https://github.com/peerlibrary/peerlibrary
1533 days ago
Unfiled. Edited by Mitar 1533 days ago
  1. Mitar Milutinovic - PeerLibrary - what is new and what we had to solve to get there

Contact Support

Please check out our How-to Guide and FAQ first to see if your question is already answered! :)

If you have a feature request, please add it to this pad. Thanks!

Log in