I'm using minimongoid on my meteor project and I don't know if before Create and validations are done server side or client. Does anyone know ?
From its package.js file it looks like both! Also mentioned in the github readme.
So you can share the model files between the client and server. I'm not absolutely certain however that if you insert a model on the client and its been fiddled with by a hacker or something that it will be validated on the server automagically.
You might have to also validate it on the server too. The best place to do this would be in your collection's .allow method. Looking at the source of minimongoid there isn't anything tied up to .allow or .deny so you will need to validate it on the server with these.
Related
I am little unclear on the ‘secure sever code’ section of the meteor guide as to how code remains secure and accessible. I understand that you can place code in a server directory and call it from a place where code it shared, but how does this work with imports?
Won't you need to import the secure function into the shared code location so it works on the server. Yet, that secure code is not available on the client, as expected, so will create an error. Is there some sort of conditional import you have to set up (depending on whether the code is run on the server or client) to make this work?
Could someone let me know where my understanding on this topic is lacking?
Many thanks.
Many tutorials say to place some code in lib/file.js where it can run on both client and server.
Does that also allow the client to modify the code as they like? Thanks
Updating my answer to clarify what David is saying below:
You can change the definitions of any client-side accessible code you want. Server code itself cannot be changed while it's running unless you're using eval() or are able to mess with the file system from the client. This is important because even if you change the client code to do something that would potentially look malicious, the server code wouldn't execute that code as such since they are defined in two completely separate places (your machine on the client versus the actual server) If you mean can the client can see the code being executed, then yes, they'll be able to see the minified version of anything in lib/file.js.
I'm implementing a very light weight (embedded) OSGi framework which runs on a target piece of hardware. To attach a console I'm using org.apache.felix.gogo.shell and org.apache.felix.shell.remote.
To date, I've logged all custom messages using System.out.println which has worked fine, but now that I'm using the remote console I require something that will allow me to 'print' my messages to the OSGi console (and hopefully appear both on the target's console as well as the telnet console provided by felix.shell.remote).
I'm guessing there must be a way to get a handle to an OutputStream (or similar) to do this; My question is how? It seems that most people redirect their stdout etc. to solve problems like this.
I'm using declarative services, so I was hoping to be able to setup a component which attaches a referenced service (not important, but would make it nice and neat).
Any help is greatly appreciated.
The best way is to use logging for custom messages using the OSGi Log Service. That way you can get recent logs from the LogReader service from inside your shell or webconsole. If you insist on using popular frameworks like log4j etc. then you can get a bridge with Pax logging.
Alternatively, redirecting the output to a file in a known location works. You can then make a command in gogo that views that file or provide a tail function that continuously displays the new parts of the file.
I write a lot of code, most of it I throw away eventually when I am done with it; recently I was thinking that if I just kept every small piece of utility script I wrote, named it, tagged it and filed it in a dev shell, I will never loose the code, and on top of that I won't need to redo something I have done already, which is the main motivation, as I keep finding myself writing something I've done earlier.
Is there a ASP.NET shell style environment anywhere?
If not, what would be the best way to go about this?
I am looking to be able to do the following:
Write big or small bits of code.
Derive from or chain together alread written code/libraries/services.
Ability to have everything on my desktop (would that mean IIS on the desktop? or is there an lighter weight mechanism?), sync'ed with the server at home, so if I am on the move I can still access this and make this part of my day-to-day workflow.
You could build a unique solution, with many class library projects inside. Each project would address a specific scenario, something like this:
MyStuff (Solution)
MyStuff.Common
MyStuff.Validation
MyStuff.Web
MyStuff.Encryption
etc.
Then you can put this solution on an online versioning service like bitbucket or assembla, so you can access your source code from anywhere, edit it and commit it back to the server. This way you get the advantages of versioning and you store your code on a remote server so even if your harddisk breaks it's not a problem, cause what's on the server is what matters.
You should either look into a source control system (Git perhaps?) or into a file storage / syncing / sharing service like DropBox.
DropBox would allow you to access code snippets from wherever you are and works really easily (just drop a file into a folder).
If you need versioning and branching you're going to have to look into a source control system. Since you have a server at home, that should be no problem.
I maintain a web application that is painful to upgrade. It's not painful because the code is bad, but because there are a lot of devices connected to this application via the web and getting them to update their clients is a lot like moving concrete.
So I had an idea that I could simply present a different version of the application to different customers. The session stores the client information. So what I'd ultimately like to do is peak at that session and then use that to present the "correct" version of my app to them.
Physically the apps are stored in a manner like such:
C:\Program Files\Company\Program\Version\Web\WebApp
So you can see that I could have multiple versions installed at once. Basically if customer A goes to the site they get presented with C:\Program Files\Company\Program\1.0.0.0\Web\WebApp\foo.aspx And if customer B visits the site, they get to see C:\Program Files\Company\Program\2.0.0.0\Web\WebApp\foo.aspx.
I initially thought of using the IIS rewrite module, but I really don't want to redirect them. I want this to be seamless. Any ideas on how this can be implemented?
update:
After further research, I thought it would be clever to use the Global.asax.cs to accomplish my goal. So in the Application_BeginRequest event handler, I wrote the following:
string url = Request.Url.ToString();
if (url.Contains("MyTest"))
{
Context.RewritePath("/art/test.html");
}
By the way, /art/ is a virtual directory that I grafted into this directory via IIS. This would be similar to how I would set it up in production. Anyway, I get the following error when I try this.
The virtual path '/art/test.html' maps to another application, which is not allowed.
So how do I do this then? Is there an "allowed" strategy for accomplishing this? Doing it through the Global.asax.cs would be ideal since I could use the HTTP Context to "know" which customer is connecting to the app.
Okay, I have it mostly figured out. Here's how I did it. I basically created a parent app that would route to the various versions. In that app, I use the Context.RewritePath as I did above except I added a ~ in front of the url. Now I'm having issues with the viewstate, but I think I can get it figured out from here. (I hope). I'll update this answer later when I ultimately get a perfectly working solution.