We are writing this blog post to document a change to how REST APIs work with Ultra Assignments and Tests. Previously, before Blackboard version 3900.98, you could use the createAssignment REST API and treat the resulting object like a Test. You could add more than one question of differing types, using the user interface. You could use the REST API and add more than one presentation-type question type using POST request to /learn/api/public/v1/courses/{courseId}/assessments/{assessmentId}/questions/{questionId}.

Blackboard introduced a new Assignment tool with version 3900.98. It is no longer the same as a Test. With the new Assignment tool, when you use createAssignment the assignment body is still created, but you only see the instructions, with no option to add questions, and you cannot add questions using the assessments endpoint. To create a Test you must now use the createContent endpoint. You can find more information here: Creating and Updating Content with REST APIs.

Owr very own Camilo Dominguez presented us on our bbtechies session on Wednesday April 17th 2024 the Public REST API roadmap and a bit of the Developer Portal Roadmap.

Here is the slide deck!

Cheers!

Ensuring prompt email support is crucial for achieving a seamless integration. We prioritize addressing inquiries from developers and the community promptly. However, given the volume of emails we receive daily, ranging from straightforward queries to those requiring in-depth research for the best solution or alternative, our response times may vary. Our approach to supporting email inquiries involves several phases:

Upon receipt, emails undergo the following process:

• The developer support team identifies the relevant domain associated with the request, such as Learn, Student, Reach, Finance, etc.
• The support request is then assigned to the most suitable resource available.
• Extensive research is conducted on the issue outlined in the email.
• A comprehensive response is crafted and sent out to address the email.

Below are the recommended best practices to ensure you receive the quickest, most accurate, and highest quality response:

• Ensure a Clear Subject Line:

  • Opt for a descriptive subject line summarizing the issue concisely. We recommend using the following format:
    • {Your Company Name}-{Domain Name}: {Brief Issue Description}
    • Example: YourCompanyName-AnthologyLearn: Issue with Launching Textbook Tool

• Provide Relevant Information:

  • Include all necessary details such as issue specifics, steps to replicate, and relevant test data.

• Be Concise Yet Specific:

  • Offer sufficient information to clarify the problem while avoiding unnecessary details that could potentially confuse the support team.

• One Issue per Email:

  • Focus on one problem per email to streamline communication and ensure adequate attention is given to each issue.

• Maintain a Polite and Professional Tone:

  • Uphold a respectful demeanor in your communication, regardless of any frustrations. Remember, support agents are here to assist you, and a courteous approach can enhance the interaction.

• Follow Up Appropriately:

  • Should you not receive a response within a reasonable timeframe, consider a polite follow-up. However, refrain from overwhelming the support team with numerous emails in quick succession.

We eagerly anticipate receiving full support and collaborating with your teams to ensure a successful integration.

Cheers!

Today, we had a really nice session with Mark O'Neil where he explored our roadmap for REST APIs and Developer Portal!

Have a glimpse of what's to come!

our forward looking statement must be kept in mind in this presentation

Here is the slide deck!

Cheers!

Today, we had a really nice session with Mark O'Neil where he explored our roadmap for REST APIs and Developer Portal!

Have a glimpse of what's to come!

our forward looking statement must be kept in mind in this presentation

Here is the slide deck!

Cheers!

Anthology has designed it's model for integrations in a manner which, when executed following our best practices, improves the Customer Integration Experience. Our goals in this area are multi-fold, yet all drive toward the best experience possible when Customers license, purchase, or develop integrations for enhancing their Anthology Products as campus differentiators and enablers in achieving their Teaching and Learning objectives for their Staff, Faculty, and Students.

Why is Customer Experience Important?​

Customer experience is important for Partners and Anthology Customers for many reasons. Most notably:

Customer Retention: Providing a positive customer experience can help improve customer retention rates. Customers are more likely to remain loyal to a brand if they have had a positive experience with the company.

Brand Reputation: A positive customer experience can enhance your company's reputation and help build a positive brand image. Word of mouth and online reviews are powerful marketing tools, and customers are more likely to share their positive experiences with others.

Competitive Advantage: Providing a superior customer experience can set a business apart from its competitors and give it a competitive advantage.

Overall, a positive customer experience is essential for building strong customer relationships, increasing customer loyalty, and improving the overall success of a business. This applies to our developer community as well as Anthology.

In addition to the general integration functionality, for which the integration development team is ultimately responsible, the most significant impact on the Customer Experience is installation and support of your integration.

Installation of your integration is often the first experience customers will have with your business and first impressions are lasting and influence future interactions.

How clients discover and know whom to contact for Support is also a significant influencer of impressions of your business.

Anthology has built our integration experience and best practices, with these latter two concepts in mind.

Integration Installation​

Anthology has thought long about how to simplify the integration experience for customers in the world of SaaS. In doing so we arrived at a "Register once, deploy everywhere" model for Integration developers to deliver theirr solutions. This applies to LTI 1.3 and RESTful integrations alike, and greatly simplifies installation for our mutual customers.

SaaS changed everything...​

In prior years you may have built integrations which ran on-prem or in-process alongside the Anthology product. This required customers to manage the software themselves. Under the more modern SaaS model, which is used by Anthology, the customer is no responsible for updating and maintaining the integration, as SaaS product consumers receive updates automatically.

To facilitate the SaaS model, the Anthology Developer Portal provides the means for you the Developer to register your integration once and deploy to multiple customers. Once your integration is registered in the Developer Portal an identifier is issued - this identifier is used by all customers to install your integration.

This means you have one instance of your integration and all customers use that instance. This of course imply some design concepts for your integration.

This model for delivering innovative solutions to customers provides cost savings and improved efficiency for your business. This is because instead of multiple instances (with per instance charges accrued) you only need one instance of your integration which is shared by all your customers. This is the SaaS way.

Integration Design Considerations​

Register once and Deploy anywhere means there are some differences in how you design and deliver your integration.

Note: The following pertains to development of integrations which are marketed to multiple customers. Only point 1 is pertinent to those who are developing campus-only solutions.

1. Logs and data: Integrations should maintain archives of customer logs and any integration specific data as those are not provided by Anthology products.
2. Multi-tenancy: Integrations should follow a multi-tenant model vs single tenant. Multi-tenant means one integration service delivering your integration to all your customers vs requiring a new intetegration service per customer. This means you have to design into your integration the ability for enabling individual customer accounts, likely only administrator, for any customer specific configuration.
3. Separation of Customer data: Multi-tenancy means that in addition to running a single service for your customers you are likely using a single database. This dictates a secure separation of customer data using a unique customer identifier prefix on customer-centric data keys.

Each of the above enable you to deliver a secure, efficient, and postive experience to customers at a cost savings of single instance vs multiple instance service delivery.

Best Practices​

Developer Portal Accounts​

There are really two types of Developer Portal accounts:

1. Developer Accounts: the personal accounts which are used for prototyping and testing of your integration. These are in the form of developername@domain.tld. These are often referred to as test or development _groups. These groups are restricted in the number of request which may be made w/in a 24 hour time period to non-production level settings.
2. Production Accounts: these are your accounts used for production release of your integration. Given this account's information is what customers see when they install your integration it is considered a best practice to use a mailinglist such as business@, integration_name@, or support@domain.tld. This email must be publicly reachable.
3. Production Group: This is a very specific group within your Production Account which contains your integrations. This group receives production level settings.

See Getting Started with the Developer Portal for more information.

Production Integration Release​

See our Releasing your Integration guide for production release details.

Also see LTI Registration and Deployment with Learn guide which describes Anthology's approach behind releasing LTI 1.3 integrations.

Customer Facing Documentation​

It is the integration developer's responsibility to provide the necessary documentation for a successful installation. This is greatly simplified when following our best practices for Register once, deploy anywhere.

Currently there are three things which will generate no end of consternation for customers which degrades their experience with your integration/company. These three things fall into two groups User Roles and Support.

Integration User Roles: Entitlements vs Privileges​

Aside from it not being a best practice to ask your customer to register your integration on the Developer Portal on your behalf, even worse is asking them to do so and then ask that they give your integration an Admin Role. Never, never, never ask them to do these terrible things.

Instead, develop your integration following the Register once model, and hand off your integration Identifier to your customer. If you are an LTI 1.3 provider - you are done. Your customer adds your LTI integration and sets availability to their users and they are done. No passing around of Keys and Secrets or error prone multiple copy pasting of multiple configuration strings... you hand off one integration Id which you get when you register your integration on the portal and done.

Well almost... the current exception (see The Future is Bright(er) below) is if your integration uses our REST APIs. Then your integration documentation must provide Anthology administrators with a list of privileges that need to be added to the user which is associated with your integration. The APIs list entitlements, not privileges, and therein lay a problem for Customers.

As the integration provider you want a great customer experience so you use the bookmarklet tool to determine the privileges you include in your documentation to provide guidance to admins installing your integration.

Integration Support​

Who is responsible for your integration's support?​

It probably goes without saying, but the integration vendor is responsible. Not Anthology.

When the vendor registers in the Developer Portal they provide email information which is seen by customers when they install the integration. That is why this email and contact information must be publicly reachable. That is also why it makes sense to have a specific account from which all your integrations are delivered.

See Getting Started with the Dev Portal for information.

The Future is Bright(er)​

Forward Looking Statement applies:

Statements regarding our product development initiatives, including new products and future product upgrades, updates or enhancements represent our current intentions, but may be modified, delayed or abandoned without prior notice and there is no assurance that such offering, upgrades, updates or functionality will become available unless and until they have been made generally available to our customers.

Simplification of Integration Installation​

To ensure an optimal customer experience we have a few items which we intend to deliver in 2023. Each of these enable the offset the heavy lift of the installation of any integration from customers to the developer.

Auto-Install of REST Users with Privileges​

Integrations using the REST API require association with a REST integration user who has the necessary system role privileges (never a System Administrator Role!!!).

The REST APIs identify with entitlements while the systems identify with privileges. This complicates installation of REST integrations not using Three Legged OAuth (3LO).

Late 2023 we intend to release a "manifest" model for integrations which, amongst other useful data points, identifies the entitlements required by an integration. This manifest will be used on Administrator request to install an integration to display important information about the integration to the Administrator - notably the privileges requested by the integration developer.

The now informed Administrator may choose to install the integration at which time the REST integration user is created with the necessary privileges.

No interaction on the part of the Administrator other than reviewing and accepting the installation!

LTI and REST share JWT for authN​

Currently LTI 1.3 and REST APIs use two separate authentication models. LTI 1.3 uses JSON Web Tokens (JWT) and REST uses OAuth 2 basic authentication using Key:Secret pairs.

Late 2023 the use of JWT will be optional for REST API-based integrations and JWT will be used exclusively for LTI 1.3 integrations which also use our REST APIs.

This greatly simplifies the development of LTI 1.3 integrations which use our REST APIs. The optional use of JWTs for non-LTI integrations provide an improved security model for REST API-based integrations while being backward compatible with existing REST integrations.

DevCon 2022 Presentations!

We will be adding sessions here as soon as we get the presentations! If you want to see your DevCon presentation, please write us at developers@anthology.com. All times are in ET.

Day 1 @ DevCon 2022

BB Rest Helper​

⏲ 1:00 PM - 1:45 PM Session

Creating a proof of concept for an integration from scratch can be tedious, there are many basic elements such API authentication or logs that will need to be sorted out before being able to work on meaningful code, and even then, lots of code will need to be written and tested for API Requests. This library abstracts the common and boring operations that Blackboard developers face when interfacing with the REST API so they can focus their effort in creating the cool features they need for their integrations. This library is intended to explore Blackboard REST APIs and to help create POCs for integrations. Please note this tool is not supported by Blackboard and no warranties of any kind are provided. In this presentation you will get to know the Bb_rest_helper library, and how to set up with Visual studio code and Jupyter notebooks to make the REST of your life easier

Description​

The Bb Rest Helper includes 5 classes to simpilfy common API operations with Blackboard APIs;

1. Get_Config. This class is used to get configuration variables (url,key,secret)from an external configuration file in Json format. If you are authenticating for more than one API (i.e. Learn and Collaborate) you will need separate configuration files (i.e. learn_config.json and collab_config.json).
2. Auth_Helper. This class is used to get the token that then will be used in the API calls. Provides different methods for the different APIs.
3. Bb_Requests. This class is used to simplify calls to the Blackboard Rest APIs. Provides methods for GET, POST, PUT, PATCH and DELETE requests.
4. Bb_Utils. A set of convenience functions (Logging, printing...), this will be extended over time.
5. Ally_Helper This class is used to simplify interaction with Ally as a service, includes methods to authenticate, upload a file, check processing status and retrieve the feedback. As it is an initial release for this API with limited features, it is implemented as a separate class to provide easier access to these methods rather than having to code them manually or with the Bb_rest_helper library.

Companion Links​

• Javier's GitRepo
• Pypi project link

Presentation PDF​

Day 2 @ DevCon 2022

Blackboard Learn REST APIs for Beginners​

⏲ 11:40 AM - 12:25 AM Session

Presentation PDF​

Video companion​

Migrating a B2 to LTI & REST Deep dive​

⏲ 1:45 PM - 3:00 PM Session

Moving to Ultra: A Phased Approach​

⏲ 4:15 PM - 5:00 PM Session

Day 3 @ DevCon 2022

Making ultra your own: UEF for Beginners​

⏲ 11:30 PM - 12:15 PM Session

For years, many of us have relied on Building Blocks as a way to add features and functionality into our Blackboard Learn courses. One of the best tools we ever used was the javascript Hacks tool, which leveraged the renderingHook function to allow a system administrator to further modify and customize their Learn environment with custom tools, banner, footers, etc. Unfortunately, the Ultra experience no longer supports the renderingHook function, removing the key mechanism for these customizations.

In order to restore some of these capabilities, Blackboard Learn implemented a new feature set called the Ultra Extension Framework (UEF). This new framework opens a number of doors for developers to once again customize and extend their Blackboard Learn environments after switching to the Ultra experience. The Ultra Extension Framework consists of two key components – telemetry data for user activity, and injection points to add content at various locations within the Ultra interface.

The telemetry data can include a number of different events, including hover, click, route, as well as portal windows being created and removed. After initially launching as an LTI tool, an UEF tool can subscribe to any number of these events, and typically runs as javascript inside of a hidden iframe within the Ultra interface. From there, the custom script can then submit requests to the Ultra interface to create new panels, banners, notifications, popups, or even a custom help provider.

The attached presentation will provide some sample code snippets from projects that we have deployed in our production environment, including banners and custom help providers.

Best Practices for Building Your LTI Advantage & REST Applications For Learn, From Registration through Release​

⏲ 9:00 AM - 9:45 PM Session

In this session Mark will give best practices for integrations that use LTI 1.3 and/or the Blackboard Learn REST APIs. There are many ways to improve your integration's performance and use, beginning with registration on the developer portal through the day it's installed on client systems. Given Mark's extensive experience working with 3rd-party integrations, he's selected those commonly missed best practices that, when you use them, will position your integration for maximum success.

When we started supporting LTI 1.3/Advantage (back in May of 2019) we chose to generate public/private key pairs for the tools. The tool vendor was then responsible for copying and storing those values on their side.

But the IMS Global community has moved away from that model and now suggests that tool vendors generate their own key pairs for LTI authentication and provide their public key via a JWKS URL. This model is more secure because there is not copying of a private key and allows the LTI Tool provider to follow best practices with key rotation.

We decided to follow that suggestion. If you want to register a new tool with Learn, you have to provide the JWKS URL information. And if you have an existing tool that use the Anthology-generated private key, please keep in mind that we'll be terminating support in the near future.

NOTE: Once you've made the change, you must have our mutual clients redeploy your LTI 1.3 tool. Redeploy means the following:

1. Admin -> Integrations, LTI Tool Providers -> Register LTI 1.3/Advantage Tool
2. Enter the same client ID for your tool that was previously deployed. Click the [Submit] Button.
3. Your tool will be redeployed to use your new JWKS URL.

Follow the above steps exactly. Do NOT have them delete the integration as that will destroy all existing links to your tool, which can not be recovered.

Here is a video explanation of both the steps you need to take to update your tool's JWKS URL and the step you will need to have our mutual clients take. Note that after you update your tool's JWKS URL on the developer portal our mutual clients will NOT able to use your product until after they redeploy as described above and in the video.

FAQ:

1. Is this just a background change, and it will not impact anything on the front end?
   -> There is no impact to how our mutual clients use the LTI Tool or Learn.
2. Does making the change at the central location serve the purpose, or are we required to plan anything around individual connections for separate schools?
   -> You will need to work with the individual schools to ensure that after you make the chage they redploy your tool as described above.
3. Will schools transition seamlessly once we transition from a static public key to keyset URL (JWKS), or does it require any intervention from the Black side or the school admins?
   -> The school admins will need to redeploy your tool as described above.
4. Currently, both static public key and keyset URL (JWKS) are going through successfully. Is it because Anthology hasn’t yet discontinued supporting the static public key?
   -> Anthology will continue supporting the keys that were originally provided until further notice, likely until the end of 2022*.

As always, if you have any questions, check out the contact us page and let us know!

*Statements regarding our product development initiatives, including new products and future product upgrades, updates or enhancements represent our current intentions, but may be modified, delayed or abandoned without prior notice and there is no assurance that such offering, upgrades, updates or functionality will become available unless and until they have been made generally available to our customers.

In testing with the Google Canary Chrome Browser, one of our clients discovered an issue that was blocking users from logging in to their Learn instance. After much troubleshooting, we discovered a multi-layer issue that brings us to, you guessed it, cookies.

This affects clients in SaaS with Ultra Base Navigation enabled using Ultra integrations that rely on UEF
> Review UPDATE in LTI 1.3 section. This post previously mentioned a bug that no longer exists.

Here is a brief description of the contributing factors:

First, the client had built a custom Ultra login page. The page included code designed to ensure that Learn login pages would never render inside of an iframe within Learn. It looks like this:

if ( top != self )
{
    top.location.replace( self.location.href );
}

In and of itself there's nothing wrong with it. We, at Anthology, have removed it from the default Ultra login page, but many clients use it in Original login pages, and so it's moved with them into Ultra.

If you are unsure whether you have a custom login page, visit help.blackboard.com for more information.

Secondly, when a user logged in, Ultra Extensions automatically fired off an LTI launch to UEF-enabled tools. The way UEF works is: after the LTI launch is validated, the tool redirects to the Learn REST endpoint to initiate a UserAuth flow. In our documentation, we call this a Three-Legged OAuth or 3LO. In most cases, it's a process that relies on a session cookie to hold everything together. This impending release of Chrome (and other browsers) will block this cookie because everything is happening across domains and involves the use of iframes.

So what happens is that, even though the integration is configured in Learn to not force the end-user to authorize the integration, the lack of the session cookie means that Learn has no idea that this user is logged in, so it pops open the login page.

Remember that code snippet above in the custom login page? Well, that takes over the entire browser page with the Learn login. And when the user logs in again, it renders the JavaScript meant for the UEF iframe into the page. In other words, it overtakes your Learn browser session. There is no way to actually get past that screen.

Related, this same issue affects Safari users when cross-site tracking is disabled.

So what can you do?​

Well, that depends upon who is reading this blog. If you are an administrator trying to get your users back in Learn, the most immediate fix is to remove that snippet from your login page. It won't fix your broken UEF integration, but it will at least let your users log in and interact with Learn.

If you are a developer that has built a UEF integration, we actually implemented a fix for this in April: a way to bypass the need for a session cookie in this process. In the LTI launch, we now provide what is called a one-time session cookie. This is present in both LTI 1.1 and 1.3 launches.

This one-time session cookie is added to the claims in the LTI 1.3 JWT and the form POST parameters in LTI 1.1. You can grab that value from the LTI launch, return it as a parameter in your 3LO authorization code request, and your problem will be solved.

UPDATE: This section previously mentioned a bug where the userId needed to be appended to the one_time_session token. This bug has been fixed. Your code can now use the one_time_session_token as provided by Blackboard Learn without appending the userId. Blackboard no longer appends a userId, nor expects it in the returned value. If your code does append a comma and userId, that’s OK, you don’t immediatly need to change your code it as Blackboard just ignores the comma and what comes after if those are part of the value you send back.

LTI 1.3​

In LTI 1.3, you will see the value in the https://blackboard.com/lti/claim/one_time_session_token claim. This token is made up of a specially generated token value. Here's a Python 3 code snippet to illustrate how this might look.

    # Get the value of the one time session token from the LTI claim
    one_time_session_token  = message_launch_data['https://blackboard.com/lti/claim/one_time_session_token']

    # Add the one_time_session_token to the query parameters to send to the Authorization Code endpoint
    params = {
        'redirect_uri' : Config.config['app_url'] + '/authcode/',
        'response_type' : 'code',
        'client_id' : Config.config['learn_rest_key'],
        'one_time_session_token' : one_time_session_token,
        'scope' : '*',
        'state' : str(uuid.uuid4())
    }

    # Encode the parameters
    encoded_params = urllib.parse.urlencode(params)

    # Redirect the successful LTI validation to the Authorization Code endpoint
    return(redirect(learn_url + '/learn/api/public/v1/oauth2/authorizationCode?' + encoded_params))

LTI 1.1​

By now, I hope you are using LTI 1.3, but I know many are not. As a result, we also added a one-time session token to LTI 1.1 launches. This will come in the form POST parameter ext_one_time_session_token. Just like in the 1.3 example, your application should take this value from the LTI launch, append it to the authorization code request endpoint as one_time_session_token=that_token and redirect them to the authorization code endpoint.

Summary​

We have validated this fix with one of the partners that was affected. If you are a developer, please fix the issue immediately! If you are an administrator of a Learn SaaS instance using Ultra, and you have UEF integrations, make sure you do not have that JavaScript snippet on your login page. And if you do, please remove it. Then let your UEF integration partners and developers know that this fix must be made as soon as possible.

Regardless of whether you are an administrator or a developer, please feel free to reach out to us at developers@anthology.com with any questions.

Happy coding!

First, as our documentation states, a Learn admin should never be told to associate a user with Learn admin privileges with any REST API integration, see this document. Hence we often get questions from folks on how to create a user to associate with a REST API integration that has limited capability on a Learn system. One way is to research and design your REST application to use OAuth 2 3-legged Authentication. See the documents referenced below. 3LO guarentees that the user using your REST Application can only do what they can do via the Learn UX when they are logged into Learn.

However, if your application is using our OAuth 2 2-legged Authentication read on. Or I should say, watch on. I created the following to answer the question "Is it possible to create a user that has only the necessary permissions and avoid using "Learn System Admin" user?"

The answer is yes! Here's a video explaining exactly how to proceed.

Reference Documentation:

• Managing REST Integrations in Learn: The REST Integrations Tool for System Administrators
• Basic Authentication with REST
• Three-Legged OAuth
• https://github.com/Kong/mashape-oauth/blob/master/FLOWS.md
• REST Tutorials
• Bookmarklet to help map entitlements to permissions (requires login.) or document on this site

We have spent some time over the holiday break updating and organizing our documentation better. One of the longest outstanding changes was to update the Caliper event samples from 1.0 to 1.1.

I am pleased to announce that we have finally completed this project. The event guide is largely unchanged, but the individual events have all been updated to show current sample payloads from each event, allowing you to better anticipate the messages you will receive and better plan your storage and reporting requirements.

Over the next few weeks, we will be highlighting some of the other key updates that we hope will help ease the onboarding process for new developers and make finding exactly what you need when you need it for everyone.

Happy Coding!

Back in the day, January 4, 2019 to be exact, Blackboard announced deprecation of our SOAP Web Services with this article Blackboard SOAP Web Services Deprecation

Now, almost two years later in our Learn SaaS Relase Notes we've written "As of December 31, 2020, Learn SOAP Web Services are no longer supported, as they have reached the end of life per our deprecation policy." What does this mean for you as a develoepr?

The most common concern is "Will my SOAP code continue to work in an earlier version of Learn?" or some variation. Here's a recent example: "Will this be for all versions, or will SOAP API still be available on version 3800?"

The answer is that client's self and manged-hosted systems that are on older versions of Learn will not be impacted. If your client is runnign 3800.0.3 and upgrades to the most recent Cumulative Update, the SOAP Webservices should continue to work for them.

For self and managed-hosted clients that are on 3900.0.0 and are now upgrading using the same build numbers as in SaaS, SOAP will not be supported in any release post Dec 31, 2020.

Another common quesiton is from those using the Learn LIS 2.0 SIS integration, which is SOAP based. No, we are keeping the LIS 2.0 SIS integration in the product at this time. It will not be affected.

If you have additional questions, drop a line to developers@anthology.com and we'll update this blog post with the answer.

Happy 2021!

Most people like cookies. Internet browsers used to like cookies, but a lot has changed in the last few years.

We are seeing a lot of applications stop working in some browsers because cookies are not being shared, and this post hopes to help explain why that is happening and what can be done about it.

A web application may set a cookie to track a user’s session. This is very common, however if your web application is going to be hosted in an iframe, then there’s a good chance your cookie won’t be sent back to you. This is because browsers are clamping down on sending “3rd-party” cookies back to applications hosted in an iframe. Note that a 3rd party is a site that is hosted on a domain different than the 1st party, or your web application. The reason is because these cookies can be used for tracking your internet and browsing activity. Safari has disallowed this for years as a user privacy measure.

Another case where cookies aren’t being sent back is during a form POST back to your application. If you set a cookie, then launch to a 3rd party application, if that application does a form POST back to you, the browser will likely not send your cookie back because it is trying to help prevent cross-site request forgery attacks.

Rather than detail all the scenarios and work arounds here I link to two web pages that are immensely helpful in explaining the situation and some possible workarounds.

The TL;DR is if you must set a cookie in your web application, be careful how you configure that cookie’s properties, and understand that at least in Safari, your cookies may not get passed back to you. The other browser makers are going to get as restrictive as Safari soon.

• Samesite Cookies Explained
• Samesite Cookie Recipes

New in SaaS and the forthcoming 3900 release* an @X@user.student_id@X@ template variable!.

• Statements regarding our product development initiatives, including new products and future product upgrades, updates or enhancements represent our current intentions, but may be modified, delayed or abandoned without prior notice and there is no assurance that such offering, upgrades, updates or functionality will become available unless and until they have been made generally available to our customers.

-markk

Read this article . Download Oct 2020 - Changes that will impact Learn Integrations.docx to find out how to get early access for testing.

-Mark Kauffman

Today we launched two new sections of developer documentation - Ally as a Service (AaaS) and the [Learn Ultra Extension Framework](/rest-apis/learn (UEF). These new APIs give you access to integration points and functionality that allows you to bring the power of Blackboard into your applications, and ultimately, your user's experience.

Ally as a Service is a standalone, separately licensed API to apply specific components of Ally's approach to content within your application. In its initial form, you are able to upload files, process them through Ally's accessibility checklist, and retrieve data that tells you what can be improved. This is only the tip of the iceberg, so make sure you continue to monitor this amazing capability for enhancements moving forward. For more information, including a conversation about pricing, reach out to your Account Executive.

The Ultra Extension Framework Premium APIs allow an integration to subscribe to events happening real-time in the Ultra UI, and respond to those events by interacting directly with the UI to do things like open panels, display modals, show messages and notifications, and augment the help system in Learn. Partners will need to be at a bronze level or higher to access these Premium APIs. See the partnership team for more information. If you are not a partner, check out how to become a partner. Licensed clients need only request access. Access is granted to your group in the developer portal, much like rate limits. Just open a case on Behind the Blackboard to get started!

As always, let us know if you have any questions!

Happy Coding!

New!! Visit the REST Tutorials and UEF Tutorials pages for our tutorials on these topics!!

Cheers! -markk

Be sure to revisit the Developing an LTI Advantage Solution page for the latest and greatest tutorial from DevCon 2020!

Cheers! -markk

DevCon 2020 is in the books, and what an amazing conference it was. This blog will start a weekly series in which everything Thursday, we will talk about DevCon from a content perspective. To begin this series, I want to set some context about the scope of this conference, so you, the reader, will have a baseline to base your opinions from.

So let's start with some basic figures:

• Client Registrations: 3,113​
• Institutions: 1,276​
• Countries: 54​
• Badges: 2,348​
• 358 Unique attendees to live sessions​
• 2,352 Attendees to live sessions total​
• 121,842 Collab session minutes
• Blackboarders: 300​

If we really look at this, we can come up with some interesting insights.

If we base our calculations on unique attendees to live sessions, we can see that the average attendee spent almost 6 hours actively engaged in sessions. We had 71 hours worth of sessions spread out over three separate time zones -- Monday - Friday 8am-10am EDT, Monday - Friday 1pm-3pm EDT and on five days, 3pm to 4pm, and Monday-Thursday 8pm-10pm EDT -- so the average attendee joining 6 sessions is pretty amazing.

We also issued 6.6 badges per active attendee programmatically through Badgr. These badges included attending at least 75% of a collab session associated with a session, pathways, which awarded badges based on predetermined groups of session badges, interaction with Ally, and earning points and promotions in the leaderboard.

Speaking of insights, let's take a look at a few that show how users interacted with the content provided:

Numbers and charts are cool, but what really matters from a DevCon perspective, is the experience of the attendees. Here are a few quotes that I think sum up the DevCon 2020 experience more that any statistic or chart can:

“SUPER big high-five / cheers / shout-out and ALL the other superlatives out to @Scott Hurrey and all that helped make this 2020 DevCon !!!! have greatly enjoyed it in this time of Social Distancing”​

• Kevin Squire, PA Virtual Charter School

“Thanks @shurrey Scott for an awesome experience.. and thank you to all the presenters as well as participants. Look forward to continue networking and finding better solutions for students and faculty.”​

• Arokia Raj, INTI International Universities and Colleges, Malaysia

“A big thank you to @shurrey and colleagues from @Blackboard for making the 2020 #DevCon a really special online experience. Spreading the event out over a fortnight gave participants a chance to practice and play, not just listen. Fun in dark times.”​

• Malcolm Murray, Durham

To summarize, DevCon 2020 was a unique experience, and one that gave me a little bit of normalcy. Of course I would rather see everyone in person, but since I can't, I was extremely happy we could have a virtual get-together.

Happy Coding! -scott

DevCon 2020 kicked off in full force this week with clients, partners and Blackboarders around the world coming together in Learn Ultra to network, share knowledge, and dig deeper into Blackboard tech.

We’ve had a record number of people at DevCon with 2,273 attendees logging in from 973 institutions and 43 countries throughout the week. We also had some amazing content, delivered all over the world.

Our most-attended session was 'Collaborate Best Practices' presented by Amy Eyre from the University of York and Helga Gunnarsdottir from the University of the West of England (UWE), co-chairs of the EMEA Mobile and Collaborate User Group, affectionately known as MoCo.

Other highlights include the 'May the Data be with you' series. I definitly miss seeing everyone in person, so the lively interaction in these sessions led by a talented group of System Administrators was definitely the next best thing. Big thanks to Casey Eubank from WSU Tech, Chris Bray from Arkansas, Heather Crites from Columbia State Community College, Dan Gioia from St. Louis Community College, Bradley Lawton from Louisville, and Mark Reynolds from University of Illinois at Urbana-Champaign.

There were also a number of other sessions that were well-attended and extremely interesting, including:

• 'LTI Advantage for System Administrators', a thorough overview from Blackboard's own Eric Preston of the history of LTI, the new LTI Advantage spec, and everything a system administrator needs to know about LTI.
• 'A Galaxy of Learn Data - Blast off with BbData & Python!' was a look at the amazing work that Mike Bechtel from Indian River State College has done using Python to interact with Blackboard Data.
• 'Turning any resource into an LTI tool to optimize Base Navigation' from University of Chicago's Szymon Machajewski was an entertaining look at a simple tool that turns any URL into an LTI tool that can be embedded into any LTI-compliant platform.

I wish I could list highlights of all of the sessions, but in the spirit of brevity, let me just say thank you. Thank you to all of our presenters for taking the time out of your busy schedule -- sometimes crazy early, crazy late, or both -- to share your knowledge with the rest of our community. There is no better way to support and learn from each other than open communication. I look forward to building on this virtual DevCon to continue that global communication.

Next week, we’ll continue running sessions three times each day to accommodate all time zones and schedules. Here are some sessions you won’t want to miss:

• The Python and the Postman - REST APIs for Beginners
• Migrate Your B2 to LTI Advantage and REST
• Models for Learn REST and LTI Integrations
• The DevCon Gamification Query: what we built, how we designed it, and how might you adapt it for your institution
• GUI Admin Tips and Tricks Unconference Sessions

And don’t forget about Hackboard: Data. This weeklong event will allow attendees to build meaningful insights against the wealth of information Blackboard Data puts at your fingertips. We’ll kick off Monday and finish on Friday, with two Q&A sessions in between. So add the Hackboard: Data session to your schedule and join us for the kickoff on Monday!

As I write this, it looks like Mark Reynolds is atop the leaderboard, with Bradley Lawton and Eric Silva fast on his heels. And I would be remiss if I didn't mention our badging with Badgr. So far (not including Friday), we have awarded 480 badges, including:

• Arokia Raj, INTI Internation University and Colleges in Malaysia, who earned the 'Daily Champions Champion' badge by earning all of the Daily Champion badges.
• Mark Carroll, Mark Reynolds, and Kevin Lowey who earned the 'Let's take it data day' badge, by attending 4 of the 8 data-based (see what I did there?) sessions.
• Mark Carroll, Alicia Dunlap, Irene Rojas, and Elizabeth Barcena, who have attended more than half of the LTI sessions, earning them the 'LTI Advantageous' badge.

Hoping to see all who attended and more back on Monday as we get ready for another week of great content from our clients (and us, too).

Now you know, I can't let the chance to write some code poetry pass by:

DevCon – one week down.
Full of tips, tricks, chits and chats.
Earn those badges yet?