I've done a ton of research on this and I've seen people asking this, but never seen an answer: Is there any way that anyone has discovered to work with the Docusign API from within Quickbase? As far as I can tell, quickbase only supports Javascript, without Node.js, and Docusign doesn't support CORS. I tried talking to both companies who won't say it isn't possible, but aren't really giving me any direction beyond the official docs, which aren't helping.
I suggest that you build a small Gateway that will support cors on one side and the DocuSign API on the other side
Related
I kept searching for a tutorial that explains the logic behind facebook notifications (or any similar notifications system) and I couldn't really find any that approach this.
I mean those notifications with a dropdown that say "X commented on your picture" and so on.
How would you guys build such a feature with node? (socket.io?) What would you store in the database? If someone can give me some references would be great.
I never did a notification system to be honest, but as far as I know, yes, sockets (and for node specifically, socket.io, it's the only one I know) can allow you to do that easily, you should look at their basic documentation to learn more about it and understand how it can be done, and yes you can at the same time as notifying the user about the like, store it in a database for further reference, you can store the time, the profile who liked the post, the ID of the post, this kind of things.
Hope I'm clear and that you will find socket.io documentation easy enough to build your notification system!
I am interested in building a tool that allows business to manage DMs from a web app.
I'm wondering if anyone has any experience working with Instagram's API in this capacity, and if so, whether there is any red tape to be aware of.
I very much appreciate the insights!
Currently, there is no API for Instagram DMs. There has been no mention of opening up in the future, either.
I'm a newbie in Node.js and after doing initial learning on Node.js, I find it rather confusing to find out any best practices. My project requires to build a real-time notification system such that, when something happens at the server side or any of the connected clients, a notification can pop up at all connected clients. I couldn't find any official recommendations on what's the best approach and tools to take. I saw there are various frameworks written in Node.js seem able to do the job, but I'm hoping some one can give me some direction.
Thank you in advance.
Start with Angularfire if you want to code less.
You can create real-time apps without a backend part like so: https://github.com/tastejs/todomvc/blob/master/examples/firebase-angular/js/app.js
Note, this is a Q&A site. Ask a question next time. "Please direct me" is not allowed to ask here.
I'm trying to secure my play application but I have no idea where to start. In play tutorial I have not found any chapter about that topic. As far as I see security topic is changing between play versions. So what are You guys using to secure Yours applications.
I'm new in Play so please forgive me if I'm asking obvious questions.
Edit:
Ok, maby question was't clear enough(I'm really sorry about that). When talking about security I mean that I need something to deal with users credentials and tool which allows me to restrict access to some pages and eventually to some rest actions in my application.
Edit2:
I'll try deadbolt2 now and we'll see how does it works. But I still encurage You guys to share Your knowledge about Play security with others:)
The documentation seems to still be a bit lacklustre on this topic, but essentially, authentication/authorisation functionality is usually performed using Action composition, which is the basis of reusable controller code in Play. There an example here (also linked from the docs that should help give you the general idea.)
Action composition in Play 2.2.x is done using ActionBuilders. These take a block which accepts a request and returns a Future[SimpleResult]. This allows the action builder to either execute the given block, or return a different Future[SimpleResult] (say, an Unauthorized in the case that a user's credentials did not check out.)
In our app we use the Play2-auth module for handling authentication with session cookies. This has (just) been updated to work with Play 2.2.x but uses a slightly different mechanism for action composition (stackable controllers.) You might be best off working out how the precise functionality you need can be accomplished just using the native framework tools before adding a dependency to it.
I agree with the other answers but just add that I use securesocial to integrate with other auth providers (google, FB, etc...), so I don't have to do auth myself. It's quite easy to get up and running.
https://github.com/jaliss/securesocial
Access control, security, etc. is a very wide topic, because it means very different things depending on context. This may be one of the reasons why Play has little documentation for it, which puzzled me at the beginning as well.
Play2 has some security helpers, namely it's the Authenticated method, for some insights on how to use it, check the comments in the source code. Its a simple method that you could implement yourself, and most do. It, essentially, just proposes a structure for where to place your methods that would check if request is authenticated and what to do if it's not.
Play2 also has some cryptography logic, which is used for signing cookies.
That's about it, you don't have any more pre-built security structures, but that's a good thing, because you don't want the framework making decisions like that for you, if it doesn't know in what context it will be used.
What is essential is to go and research how attacks relevant to your application are carried out, best practices and so on. I recommend going to OWASP, particularly the OWASP Cheat Sheets. If the list of Cheat Sheets seems intimidating start with the OWASP Top Ten Cheat Sheet. Don't mind the large volume of information, it's very useful knowledge.
Trying to find a solution to this, we have our LMS Server, and content servers all across the US, so the user gets their content from the closest location.
I've come across a solution using SCO-Fetcher, mentioned in these two links below and illustrated below, but I cannot find any information on how to implement a similar solution.
here: http://elearningrandomwalk.blogspot.com/2006/08/sco-fetcher.html
and here: http://www.adlnet.gov/Technologies/scorm/SCORMSDocuments/SCORM%20Resources/ADL_CrossDomainScripting_1_0.pdf
If anyone has any thoughts or information regarding this, it would be most appreciated.
I work for a content provider who has had to interface with a lot of different LMSs and cross-domain has always been a painful issue.
The document you linked to not-withstanding, SCORM doesn't really cater for cross-domain at all. My experiences with cross-domain has been against the AICC standard. In the past we've used a signed java applet to perform the cross-domain communications, but currently we are using a little hidden flash* SWF file which we talk to via javascript. This requires the LMS to have a crossdomain.xml file installed on their web server to allow the communication, which some of our customers balk at.
* Our product heavily uses flash already, so this was not an onerous requirement for us.
The solution that we are seriously considering now is a variation on the "Run-time service on Content Server" as suggested in section 4.8 of the cross-domain scripting document.
The content server would run the courseware itself, as if it were an LMS, and proxy all the API calls to the real LMS. The diagram below shows the communication paths:
Also, your launch URL wouldn't be directly to the content (e.g., http://abc.com/content/sco.html) but to the software application on the content server (e.g., http://abc.com/access.php?content=sco.html&permissions=OAUTH_ID), which would then serve the content as if it was an LMS itself.
Also, just came across this article on cross-domain communication which, while not SCORM specific, might provide some alternative ideas for implementation.
I know this is an old question, but thought I'd share: I had a similar situation a few years ago and settled on an iframe hack to get around the cross-domain restrictions. All it requires is a bit of JavaScript and HTML. It works on older browsers, including IE6.
Chuck, what solution did you wind up using?