みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 (優しく回答しましょう)
You are not logged in.
Pages: 1
いつもお世話になっています。
FM15serverを今後使用予定です。 クライアントはFM15を使用する予定です。
今複数のファイルを部内で扱っています。
まだサーバーは導入していないので1つのPCで ファイルを開く→ログイン(履歴の取得)→閉じる→(必要なら)違うファイルを開く→ログイン→・・・
のようにしています。
今後、サーバーを導入することが決定しました。
そのときに各個人のPCにFMPro15をインストールします。
その際に、1つ1つのファイルを開いたときにログインするのではなく、大元のファイルでログインしそこから他のファイルを開いた時にファイルを開いた履歴だけをとるみたいなやり方が出来ないかと考えています。
ファイル数は今のところ5個程度ですが、今後増えていく予定です。
ユーザーは増減があります。
このようなことは出来ますか?
また、やらないほうがいいとかはありますか?
漠然とした質問で申し訳ないですが宜しくお願い致します。
Offline
履歴は、サーバー側swログが取られますので、それで十分かどうかを確認されれば良いと思います。評価版で確認してみられてはいかがでしょう。
Offline
Logの残し方の例です。
Logファイルを作成し、
スクリプトを追加。
スクリプト例:
スクリプト名:Add_Log($TimeStamp,$Title,$Log)
変数を設定 [$er; 値:Evaluate ( "Let ( [" & Get ( スクリプト引数 ) & "] ; 0 )" )]
If [ not IsEmpty ( $TimeStamp )]
新規レコード/検索条件
フィールド設定 [Logs::TimeStamp; $TimeStamp]
フィールド設定 [Logs::Title; $Title]
フィールド設定 [Logs::Log; $Log]
End If
フィールドへ移動 []各ファイル(ログを取りたいファイル)の「外部データソース」に上記 Logファイル を追加。
任意のタイミングで以下のスクリプトを実行。
スクリプト実行 [「Add_log($TimeStamp,$Log)」 , ファイル: 「Logs」; 引数: "$TimeStamp=" & Quote ( Get ( タイムスタンプ ) ) & ";$Log=" & Quote ( ".....")]
Offline
Shin様
ありがとうございます。
確認してみます。
qb_dp様
ありがとうございます。
質問させてください。
新しくログ専用のファイルを作成するということでしょうか?
それとも大元のファイルにログ用のテーブルを作成するのでしょうか?
私の勉強不足で申し訳ないですがスクリプト内容の理解が難しいのでよければ簡単に教えていただけないでしょうか?
Offline
私が投稿したものは、LOGのとり方の一例です。
takaさんの「やりたい事」が何かは、理解できていません。
なので、
新しくログ専用のファイルを作成するということでしょうか?
それとも大元のファイルにログ用のテーブルを作成するのでしょうか?
それは、分かりません。
私の勉強不足で申し訳ないですがスクリプト内容の理解が難しいのでよければ簡単に教えていただけないでしょうか?
ん~。「理解するために」私が提示した「Logの残し方の例」を作ってみるのが良いと思いますよ。
その上でまた、分からないことがあれば質問してみてはいかがでしょう。
Last edited by qb_dp (2017-03-02 14:51:38)
Offline
私もtakaさんのやりたいことが分からないのですが。
現行のファイルでログイン履歴が取れているようですので、そのままサーバーで運用すれば良くて、何か新しいことをする必要はないように見えます。
Offline
qb_dp様 yaya様
ありがとうございます。
申し訳ないです。
今現在「Aファイル」「Bファイル」「Cファイル」「Dファイル」「Eファイル」の5ファイルを作成し、運用しています。
これは作った私が悪いのですがその時は知識不足でログインシステムがあったりなかったりとばらばらです。
また、各ファイルが独立しているのでファイルを開くたびにログインを繰り返すことになります。
何回もログインするのが面倒くさく思えて新たに「Fファイル」をつくり、そのファイルでログイン→各ファイルを開くという動線に変えていきたいと考えています。
Fファイルでログイン後、Aファイルを開いたらAファイルを開いた履歴、Bファイルを開いたらBファイルを開いた履歴がFファイルに残るようにできればなぁと漠然と考えていました。
今までファイルとファイルを繋げたことがなかったため、このようなやり方はいいのか悪いのかを聞きたかったともし大丈夫ならログイン履歴をとる良いやり方がないかなと思って質問させていただきました。
qb_dp様のログイン履歴のとり方やってみます。
確かにやってみないと何も始まらないですね。
ありがとうございます。
Offline
あ~...。履歴を残したいのでは無いんですね。
「ファイル:A」と「ファイル:B」で アカウント|パスワード が同じ場合、
「ファイル:A」からスクリプト又は、ボタンで
ファイルを開く[「ファイル:B」]
とすると、アカウント|パスワード の入力無しで、「ファイル:B」を開くことが出来ます。
ファイル間で スクリプトやリレーションで 別ファイルを開く場合、 アカウント|パスワード が、引き継がれます。
Offline
アカウントの設定を行えばいいのでしょうが。ただ、アカウント名は判明しますが、パスワードは管理者でも知り得ませんね。ユーザーにログインしていってもらうか、アカウントを管理するファイルを別に作り、そこから制御していく方法も考えられた方がいいかもしれません。
また、いっそのこと、各ファイルのテーブルをまとめてしまい、1ファイルにしてしまう、という方法もあります。全体の構成にもよりますが、これが一番最善策かも。
Offline
qb_dp様
ありがとうございます。
一応ログインの履歴とFファイルから他のファイルを開いた履歴の2つ取る予定です。
同じ場合ならそのアカウントがそのまま使えるのですね。一応全部統一してあるのでそのままファイルを開くでいけそうなのはよかったです。
Shin様
ありがとうございます。
Fファイルにアカウントを管理するテーブルを作ろうと思っています。
アカウント設定は「Administrator」と「User」の2つにしようと思っています。
「Administrator」のパスワード「1111」 「User」のパスワード「2222」をアカウントで設定
スタッフテーブルを作成
氏名「Aさん」アカウント「Administrator」パスワード「000」
氏名「Bさん」アカウント「User」パスワード「aaa」
氏名「Cさん」アカウント「User」パスワード「bbb」
氏名「Dさん」アカウント「User」パスワード「ccc」
Fファイルで選択した氏名に対してパスワードを入力、氏名とパスワードがあっていた場合、そのアカウント(administrator or User)に応じたパスワード(1111 or 2222) で実際にログインとしたいと考えています。
Offline
ログを取ることを考えなければFファイルを作らずに起動センターで間に合うような気がします。
アカウントとパスワードについては解釈が間違ってますのでマニュアルを見てください。1つのアカウントに複数のパスワードは設定できません。
それとも、独自アカウントシステムを作ろうとお考えですか?
Offline
yaya様
説明がへたくそで申し訳ありません。
ファイル<管理<セキュリティ のアカウント設定は「Administrator(password:1111)」と「User(password:2222)」の2つです。
その他アカウント管理テーブルを作りたいと思ってます。
アカウント管理テーブル:「ユーザー氏名F」「アカウント設定F」「パスワードF」
ユーザー氏名F アカウント設定F パスワードF
Aさん Administrator 000
Bさん User aaa
Cさん User bbb
Dさん User ccc
とレコードを作成。Administrator以外は自分のパスワード以外見れないようにします。
ログインのときに自分の名前を指定し、グローバルフィールドにパスワードを入力。
氏名とパスワードが「アカウント管理テーブル::ユーザー氏名F」「アカウント管理テーブル::パスワードF」と一緒なら「アカウント管理テーブル::アカウント設定F」のアカウントで自動的にログインするようにしようと思っています。
名前がわからなくなるのでグローバルフィールドに格納したままにしてログ取得に活用できないか考えています。
Last edited by taka (2017-03-03 09:02:29)
Offline
管理されている人数にもよるとは思いますが、一人1個のアカウントを作成していき、全ファイルに同じ設定をしてしまうのがベストでしょう。パスワードを下手に保存しておくと、管理が大変ですし、万が一それが漏れた場合に情報の真正性が失われます。
その運用でしたら、アカウント名を取得すれば、いつでも誰がログインしているかは解りますね。
Offline
Shin様
ありがとうございます。
ユーザー数はだいたい20人くらいです。
一人1個のアカウントというのは セキュリティのアカウント設定に20人分を登録するという解釈でいいでしょうか?
アカウント設定のパスワードはスクリプト内にしか書いてなくて、そのスクリプトをユーザーは閲覧できないようにしています。
インターネットには接続していないので本当に部署内のみのネットワークとなります。
Administratorは今のところ私しか設定していませんので、私のパスワードがもれない限りは大丈夫だと思っているのですが甘いでしょうか?
Offline
甘いでしょう。というより、個々人での管理は必要になる可能性は高いですし、各ユーザーの固有値(例えば名前など)を利用する必要が必ず出てくるはずです。また、他のユーザーとのレコード共有や閲覧制限、編集制限等も必要になると思います。
私の提案しているのは、各ファイル全てに、ユーザー毎のアカウントとパスワードを設定する方法です。同じアカウント名で同じパスワードを設定しておけば、ファイル間の移動は楽ですよ。
Offline
Shin様
ありがとうございます。いろいろと考え立つ森ですがまだまだ考えなければいけないんですね。奥が深い・・・
編集制限に関しては一度レコードを登録(ロックをかける)したあとに編集する場合は必ずログが残るようにしています。
これはadministratorもUserも一緒です。誰が・・・の部分は名前を格納したグローバルフィールドから持ってこようとしています。
レコード共有や閲覧制限は今まで考えたこともなかったです。
個別にアカウントを設定することでどのようなところが有利になるのでしょうか?
Offline
各ファイルにアカウントを20づつ作ると言うのが面倒なので独自のアカウント管理をなさろうとしているのだと思いますが、
FileMaker標準のアカウント管理機能を普通に使ったほうが、良いですよ。
「各ファイルにアカウントを20づつ作る」という事をカンタンにしましょう。
各ファイルにユーザーに摘要する「アクセス権セット」を同じ名前で作成しておきます。
アカウントを追加するスクリプトを各ファイルに設定します。
一つ作れば、あとは、コピー&ペーストでOK。
アカウントを追加するスクリプト
スクリプト名:Add_Account[{アクセス権セット名}](Account,Password)
変数を設定 [$argu; 値:Get ( スクリプト引数 )]
If [IsEmpty ( $argu )]
現在のスクリプト終了 []
End If
変数を設定 [$Account; 値:GetValue ( $argu ; 1 )]
変数を設定 [$Password; 値:GetValue ( $argu ; 2 )]
If [IsEmpty ( $Account ) or IsEmpty ( $Password )]
現在のスクリプト終了 []
End If
アカウントを追加 [アカウント名: $Account; パスワード: $Password; アクセス権セット: 「{アクセス権セット名}」]
現在のスクリプト終了 [結果: Get ( 最終エラー ) & " " & Get ( ファイル名 )]
上記のスクリプトを「ユーザー管理ファイル」から実行します。
ユーザー管理ファイル
フィールド:Account
フィールド:Password
スクリプト名:Add_Account[{アクセス権セット名}]
スクリプト実行 [「Add_Account[{アクセス権セット名}](Account,Password)」 , ファイル: 「ファイルA」; 引数: user::Account & ¶ & user::Password]
フィールド設定 [Account_Settings::結果; Account_Settings::結果 & ¶ & Get ( スクリプトの結果 )]スクリプト実行 [「Add_Account[{アクセス権セット名}](Account,Password)」 , ファイル: 「ファイルB」; 引数: user::Account & ¶ & user::Password]
フィールド設定 [Account_Settings::結果; Account_Settings::結果 & ¶ & Get ( スクリプトの結果 )]スクリプト実行 [「Add_Account[{アクセス権セット名}](Account,Password)」 , ファイル: 「ファイルC」; 引数: user::Account & ¶ & user::Password]
フィールド設定 [Account_Settings::結果; Account_Settings::結果 & ¶ & Get ( スクリプトの結果 )]
.....
エラーコード
0|正常
9|アクセス権が不十分です
12|名前がすでに存在します
213|ユーザアカウントまたはパスワードが存在しません
ちなみに、
アカウントを削除するスクリプトは以下のような感じで。
スクリプト名:Delete_Account(Account)
変数を設定 [$Account; 値:Get ( スクリプト引数 )]
If [IsEmpty ( $Account )]
現在のスクリプト終了 []
End If
アカウントを削除 [アカウント名: $Account]
現在のスクリプト終了 [結果: Get ( 最終エラー ) & " " & Get ( ファイル名 )]
各A~E のファイルに以下の2つのスクリプトを設定しておけば、「ユーザー管理ファイル」からアカウントのコントロールが行なえます。
スクリプト名:Add_Account[{アクセス権セット名}](Account,Password)
スクリプト名:Delete_Account(Account)
Last edited by qb_dp (2017-03-03 17:39:58)
Offline
私も、以前似たようなことで悩んでいましたが・・・
ユーザーの管理はFilemakerの機能は使わないという方法で落ち着きました。
takaさんの書かれた方法に近いですが
ユーザー管理テーブルを作ってアカウントとパスワードを保存、
各ユーザーのPCに置いたショートカットでスターターファイルを開き
そこでアカウントとパスワードを入力させて
再ログインスクリプトを走らせるといった具合ですね。
個別ユーザーの判断はグローバルフィールドにユーザーIDを保存することで解決しています。
なんというか、filemakerのデフォルトのアクセス権管理があやういなーと思って。
それでしかできないことは確かにあります。
アクセス権によってレコード表示や操作を制限したりですね。
でも、それってよほど緻密に設計したシステムじゃないと
予期せぬ誤動作を引き起こしかねないと思います。
特定アクセス権を持ったものにしか表示させないレコードや編集させないフィールドがあるなら、
そもそも編集用のレイアウトを表示させるかどうか、という部分を
システムの作りこみをすることでユーザーごとに分岐させるべき、という考えですね。
filemakerデフォルト機能でやるのはよほどの経験と勉強と計画性が必要です。
Offline
FM6 以前しか知らない方や、FM 以外のシステムしか知らない方でしたら、その考え方はある意味正しいと思いますが,FM7 以降では,全く変わっています。
おそらく、FM7以降でのアクセス権セットとアカウントの概念を完全に理解されていないのでは。そこをきちんと理解されると、考え方が改らたまりますよ。
> それってよほど緻密に設計したシステムじゃないと
> 予期せぬ誤動作を引き起こしかねないと思います。
経験的には,グループアカウントでの運用の際に起こりえる事では無いかと思いますが。
アカウント管理を別に行ない,実際のファイルへのアクセスは、グループアカウントで行なう,というやり方の方が,超熟練者の取る方法です。とくに、このグループ数が1個ならまあまあの手間でしょうが,それが5を超えるくらいになると,少しの変更で数百のスクリプトの書き換えが発生する様になります。この方が管理にかかる手間は数倍になりますし,スクリプトのつくり込みなどの面倒さの量も数倍になります。
実際の運用への制限は、アクセス権セットでの設定です。その設定も、レコード毎の新規・閲覧・編集・削除のそれぞれについて条件付きで設定が可能で、さらに、フィールド事の設定もある程度可能です。もちろん、テーブル単位やレイアウトについても、細かい設定が可能です。これを、スクリプトで全て実行するには、膨大な行数とレイアウト上の全てのフィールドへのトリガー設定が必要でしょうね。
また、アカウントその物の設定は、所属させるアクセス権セットの設定以外はほとんど有りませんよ。
セキュリティーの設定、特に、ファイルやレコードへのアクセス制限の部分は、最も気を使う所で、精密な設計が必要です。その設計には、長期の見通しと熟練が必要でしょう。
FM の標準機能を使っていく際には、ある程度ラフな見通しで十分でしょう。それは、アクセス権セットを追加し、アカウントを引っ越し、細かいスクリプトの編集は、分岐させている部分を見直すだけでほぼ終わります。
Last edited by Shin (2017-03-05 22:21:41)
Offline
qb_dp様
ありがとうございます。
まったく持っておっしゃるとおりです。少々面倒だったのでアカウント管理テーブルを作る方法をとりました。
また、アカウント管理テーブルを作る方法で問題ないと思っていたところもあります。
スクリプトを教えていただいてありがとうございます。
このよゆうに簡便な方法を考えられるようになりたいと思いました。
まずやってみます。
midr様
貴重なご意見ありがとうございます。正直同じような考えを持った人がいて下さったこと、とてもうれしいです。
参考に教えていただきたいのですがデフォルトのアクセス権管理が危ないと感じたのはどこの部分でしょうか?
Shin様
ありがとうございます。
グループごとに分ける予定はないのでデフォルトのアカウント管理でやろうと思います。
アクセス権設定をそこまで細かくやったことがなかったので今回しっかり勉強して設定してみたいと思います。
Offline
Pages: 1
[ Generated in 0.008 seconds, 7 queries executed - Memory usage: 631.25 KiB (Peak: 663.79 KiB) ]