GNDの課題

アルティウムとの関係に応じて、Altium Platformで提供されるサービスは、Altium Designer内から、またはプラットフォームのブラウザベースのインターフェースから体験することができます。このページでは後者を取り上げ、Altium Accountを登録し、Altium Platform Interface にサインインすると表示されるものの概要を説明します。 Altium 365プラットフォームのセキュリティ、信頼性、プライバシー、コンプライアンスに関する最新情報については、Altium 365 Trust Centerをご覧ください。 ITARやEARのような米国政府のセキュリティ規制への準拠を必要とする組織のために、アルティウムはAWS GovCloudリージョンで動作し、追加のデータ保護対策を提供する米国ベースのAltium 365 GovCloud 。…

Altium 365 は、プロジェクトのソースファイル用 Git リポジトリをホストできます。Altium Designer はこれらのリポジトリに対して native client として動作しますが、標準の Git クライアントを使って、通常の Git リモートと同様に — clone、 pull、 push などの操作も行えます。 このページでは、次の内容を説明します: Altium 365 API を通じてプロジェクトのリポジトリ URL を確認する方法。 Altium 365 アクセストークンを使用して Git リクエストを認証する方法。 Git リポジトリの操作方法 ステップ 1: リポジトリ URL を取得する リポジトリの詳細は Altium 365 API を通じて公開されています。プロジェクトをクエリし、 repositoryUrl フィールドを読み取り、それを…

スコープは、アクセストークンに許可される操作を定義します。Altium 365 API はすべてのリクエストでスコープを検証し、ある操作に必要なスコープを持たないトークンには認可エラーが返されます。 スコープは、トークンが発行されるコンテキストに基づいてプラットフォームによって割り当てられます。スコープを手動で選択することはありませんが、トークンを確認するときや API を扱うときに目にすることになります。スコープがどのように構成されているかを理解することで、そのトークンに何が許可されているのかを解釈し、アクセス境界を把握しやすくなります。 JWT トークン内のスコープ アクセストークンは JWT であり、デコードしてクレームを確認できます。scope クレームには、そのトークンの発行時に付与されたすべてのスコープが一覧表示されます。たとえば、Workspace…

リフレッシュトークンフローは、APIリクエストを認可するための、より安全な方法です。有効期間の長い単一の認証情報を直接使用する代わりに、リフレッシュトークンを有効期間の短いアクセストークンと交換します。アクセストークンの有効期限が切れたら、再度交換します。 リフレッシュトークン単体ではAPIリクエストを認可できないことに注意してください。必ず最初にリフレッシュトークンと交換する必要があります。 このフローを使用するには、Admin → Developerでトークンを作成する際にrefresh tokenオプションを選択します。作成時に、次の3つの値が発行されます。 Client ID – 連携を識別します Client secret – 交換リクエストを認証します Refresh token – アクセストークンの取得に使用します These credentials are shown…

アクセストークンは、Altium 365 APIへのリクエストを認可します。すべてのリクエストで、AuthorizationヘッダーにBearerトークンとして含めます。 アクセストークンは、次の2つの方法で取得できます。 Directly – Admin → Developerで長期有効なアクセストークンを作成する Via exchange – リフレッシュトークンを使用して短期有効なアクセストークンを生成する（このトークンは Admin → Developerには表示されません） トークンの取得方法にかかわらず、認可の方法は同じです。 認可ヘッダー Authorization: Bearer {access-token} 例：curl curl -X POST https://{workspace-domain}/api/graphql/ \ -H "Authorization:…

トークンは、Altium 365 API へのリクエストを認可するために使用される認証情報です。すべての API リクエストには、Authorization ヘッダーに有効なトークンを含める必要があります。 トークンは、Workspace の Admin → Developer で作成します。トークンを作成できるのは Workspace 管理者のみです。 Tokens are shown once. 作成時に、トークン値は一度だけ表示され、その後 Altium に保存されることも再取得できることもありません。コピーして安全に保管してください。 トークンの種類 利用可能なトークンには 2 種類あり、使用方法とセキュリティ上のトレードオフが異なります。 長期間有効なアクセストークン API リクエストで bearer トークンとして直接使用する単一の認証情報です。有効期間は作成時に設定でき…

GRID（Global Resource ID）は、Altium プラットフォーム上のあらゆるエンティティ――プロジェクト、コンポーネント、BOM、タスクなど――を識別するための、グローバルに一意で安定した識別子です。 GRIDs が存在する理由 プラットフォーム上のエンティティには通常、ローカル識別子（GUID、数値 ID）が付与されていますが、それらはそれぞれのコンテキスト内でのみ一意です。プロジェクト GUID はグローバルには一意ではなく、異なる Workspace 内の 2 つのプロジェクトが同じ GUID を持つことがあります。サプライ部品 ID も、サプライシステムの外では意味を持ちません。そのため、サービス、イベント、統合をまたいでエンティティを曖昧さなく参照することはできません。 GRIDs は、必要なコンテキストを識別子自体に直接エンコードすることで…

realm は、Altium 365 の名前付きの独立した論理インスタンスです。すべての Workspace は必ず 1 つの realm に属し、その Workspace 内のすべてのデータはその realm 内で保存および処理されます。 Realm が存在する理由 Altium 365 は、複数の地域およびデプロイメントモデルにまたがって運用されています。従来、region という用語は、地域ごとに 1 つの Altium 365 インスタンス（たとえば欧州向けに 1 つ、米国向けに 1 つ、など）を指すために使われていました。しかし現在では、その対応関係は成り立ちません。各地域では、商用 SaaS 提供に加えて複数の独立した論理インスタンスをホストできるようになっています。そこで、そのような 1 つのインスタンスを明確に指すために、realm という用語が導入されました。 商用…

Altium Identityは、Altiumの OAuth 2.0 および OpenID Connect (OIDC) に対応したIDプロバイダーです。アプリケーションはAltium Identityを通じてユーザーを認証し、そのユーザーに代わってAltium 365 APIを呼び出します。ユーザーのAltiumパスワードを直接扱うことはありません。 アプリケーションは authorization-code flow と PKCEを使用してサインインします。パブリッククライアント（デスクトップ、オンプレミス、ネイティブ、シングルページアプリ）はクライアントシークレットなしでPKCEを使用し、コンフィデンシャルクライアント（Web／サーバーバックエンド）はクライアントシークレットを追加します。すべてのリクエストとレスポンスを含む段階的なフローはGitHubで公開されています…

このセクションでは、Altium 365 プラットフォームの以下の要素について詳しく見ていきます。 Authentication – Altium Identity の認証フロー Realms – 各「realm」は、Altium 365 の名前付きで独立した論理インスタンスです。 GRID (Global Resource ID) – Altium 365 プラットフォーム上のあらゆるエンティティに対する、グローバルに一意で安定した識別子です。 Tokens – Altium 365 API へのリクエストを認可するために使用される認証情報です。 OAuth Scopes – アクセストークンに許可される操作内容を定義します。