One of my clients sent me a xAPI course which is created using Articulate Storyline 360 and published as Tin Can API for LMS. I am able to launch the course using method mentioned in below link:
Incorporating a Tin Can LRS into an LMS
So using the above method the launch URL looks like:
http://my.lms.com/TCActivityProvider/story.html
?endpoint=http://my.lms.com/lrs/endpoint/
&auth=Basic OjFjMGY4NTYxNzUwOGI4YWY0NjFkNzU5MWUxMzE1ZGQ1
&actor={"name": ["First Last"], "mbox": ["mailto:firstlast#mycompany.com"]}
&activity_id=61XkSYC1ht2_course_id
®istration=760e3480-ba55-4991-94b0-01820dbd23a2
Using the above URL which has an endpoint and credentials information, the course gets launched successfully and sents xAPI statements to LRS automatically.
But I don't want to send the parameters like auth, actor or endpoint in the URL for security reasons.
I googled for an alternative method and found the adlnet/xapi-launch and adlnet/xAPIWrapper library.
I explored the above two libraries but am confused about how it can be integrated into the LMS?
Does Articulate Storyline 360 support adlnet/xAPIWrapper?
The adlnet/xAPIWrapper is just a library that makes it easier to communicate with the LRS and requires you to determine how the endpoint and authentication credentials will be passed to the library. In other words it isn't necessarily intended to be used via LMS launch (it will work there, but doesn't have special handling for it). The xapi-launch specification you found as far as I know (at this time) has effectively zero adoption.
The other alternative would be to use cmi5 which is another specification that includes the concepts of packaging, import and launch for content that communicates via xAPI. It uses a different credential handshake process that is similar to both the launch guidelines you linked and the xapi-launch method. It uses query string parameters for the endpoint, but the LRS credentials are accessed via a separate, single use request. It has better adoption (though still early at this time), has been peer reviewed, is under the ADL umbrella, and is on more of a standards path. See https://xapi.com/cmi5/ for more about cmi5. I don't believe Articulate has yet implemented cmi5 in their products (at this time) as they are waiting for more indication for market desire, you should contact them about your interest in it if you feel it is a suitable option.
Related
I am making an application that shows real-time status for a Valorant game. like players alive, the type of weapons each play has, time remaining, etc.
Is it possible to use Riot Valorant API to do this for live matches or for previously played matches?
As per my knowledge you couldn't. But I think you should try with Riot Games' official production API, not development API.
Let me know if you find something relatable.
(This is adding onto Sanskar's answer, which I cannot comment on as I lack the required 'reputation')
I'm aware that this is an old question, but for anyone who happens to have stumbled upon this question, there is no way to obtain real-time in-game events however, there is a way to retrieve certain data from a match-- only except, not in an official way that does go against Riot Game's TOS of using third party software. Though, I wouldn't worry about this too much as long as you do not ruin the competitive integrity of the game by providing yourself with an in-game advantage over others in the game. I personally have been using this for over a year now and have not received any form of punishment for doing so.
Anyhow, back to the actual question of this thread, check out this document of API endpoints that have been scraped through monitoring HTTP traffic of the Riot Client. https://github.com/techchrism/valorant-api-docs/tree/trunk/docs/ You'll need to obtain certain authorization tokens of the Valorant account through whatever methods are available to you (I pray that it is through lawful means :) ), which highly depends on the type of endpoint. There are certain wrappers for these endpoints already made by other users somewhere on GitHub, and you can always ask for help in the small community of developers that are using these endpoints in the README of the GitHub page I sent in this post.
REMEMBER TO NOT DO ANYTHING THAT WOULD CREATE AN UNFAIR ADVANTAGE, OR ANYTHING ELSE THAT A RIOT EMPLOYEE WOULD NOT APPROVE OF USING THIS :)
I am using Facebook ads, Google ads, and an MMP for other networks. I just need to track installs as conversions. I do not serve ads in the app.
My MMP is saying that you cannot have multiple SDKs sending info to SKAdNetwork because it will post back inaccurate information. I have not read this anywhere else.
It says you should only have one SDK posting conversions to SKAdNetwork.
Screenshot of MMP's Blog post saying this
My question is do I need to remove or disable Facebook and Google's registration to SKAdNetwork within my app so they don't post conversions to SKAdNetwork?
OR
Is it ok that all 3 SDKs post to SKAdNetwork?
You technically only need to send one conversion value update and there will be some side effects if you send more than one (though if you handle all your app specific use cases then this might not matter).
Apple will send SKAN CVs to each of the networks you are using for optimization purposes so you shouldn't need to worry about that. I'd personally recommend that you streamline your own app flow to handle SKAN postbacks directly to Apple once.
SKAN 4.0 might make it more difficult if you send multiple CVs from different parties. The new features around multiple postbacks can now get sent to the ad networks based on cohort date and this could affect the optimizations that each of the ad networks use.
Currently, I have been tasked to utilize the Google People API to ask for a user's basic Google information along with their public phone numbers. So far the results have been positive.
The solution my team and I have incorporated the Google People API integration in has the capacity to be utilized across thousands of domains. As a result, my question is simply, How can my team members and I ensure that any our clients that utilize our solution with their own particular domain get our new functionality built with the Google People API?
Keep in mind, our clients have the flexibility to have http/https and any subdomain on their site. Entering each domain possibility for our client base one by one would not be an easy task. I'm seriously hoping there is a solution around the single, explicit origin entries.
Thank you for your time and help.
Warning:
You must remember that if this is source code you are giving your clients that you are not allowed to release your client id and client secret. This includes plugins and scripts.
On November 5th 2014 Google made some changes to the APIs terms of Service.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
So if your clients could view the code of your application and see your client id and secret you should not be giving it to them.
Read more about this issue Can I really not ship open source with Client ID?
Recommendation:
The best solution for you will be to instruct your users now to create there own project on Google Developer Console and create their own JS origins.
You may just have to provide your own wrapper around the target API where you authorize the client request yourself and then do the request from Google using your own credentials.
We are currently working on a web client that communicates with the server using AJAX with JSON. The client is based on gwt, and communication is over https.
The communication can be easily inspected by browser tools - is there some reasonable approach to hide this from the user, i.e. securing the protocol?
Other than standard authentication and encryption techniques used by all browsers, whatever method you come up with, it must be initiated by your JavaScript client. This means that a good hacker can deconstruct your JavaScript and figure out how you submit data.
Security usually deals with either third parties trying to intercept communication or pose as legitimate users, or malicious users trying to get access to where they are not supposed to. Once you verified that a user is legitimate, why would you try to hide user's data from the user? Maybe you can describe your use case.
EDIT:
The only way to prevent bots is to ask a question that only a human can answer (e.g. Captcha) somewhere in the workflow (i.e. before submitting important data). It's usually annoying for users, but there is no other way. Since you build a gaming platform, ask your designer to come up with some fun verification.
Just to Round off Security Checklist
1) HTTPS - you have got it set up already :)
2) Json and XSS/XSRF Web Security -
https://developers.google.com/web-toolkit/articles/security_for_gwt_applications#json-xsrf
https://developers.google.com/web-toolkit/articles/security_for_gwt_applications#json
3) BOT attacks - A decent captcha - Captcha in GWT Widget
4) Miscellaneous - https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/_gViO5aZ-WQ
I am creating a web service which uses REST web services. The client side code is written in HTML/JavaScript. My dilemma is whether I
should use the REST resource directly using AJAX calls?
or
should I create Servlets/JSPs (where REST calls will be made and data will be sent to client(AJAX/JAVSCRIPT)).
I have seen many web apps which follow the 2nd procedure but seems to me that it's doing the same thing as 1st in an indirect way.
Is there any advantage of using 2nd procedure over first?
What is the standard way to use REST services by HTML/javaScript client?
Please let me know if I am even thinking in the right direction and if not please give your valuable insight.
You can use either approach but note that browsers will enforce the same-origin policy on scripts, so if the REST service lives on a different domain than the script you will need to use a servlet/script on the same domain as the script to proxy the call to the other domain. I suspect this is why you are seeing the second approach used.
A proxy/middle-man servlet may also be useful if not all of the response is needed; you could use the servlet to strip out information that is not needed by the JavaScript to reduce the amount of data sent to the browser.
Directly accessing the resource(s) via AJAX has the obvious benefit of less overhead and is IMHO the more elegant solution, however it is also important to note that not all browsers support PUT and DELETE requests natively.
To get around this, you'll likely want to support the common "_method" hack. This stackoverflow question mentions this approach.