sandstorm.js 5.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127
  1. // Sandstorm context is detected using the METEOR_SETTINGS environment variable
  2. // in the package definition.
  3. const isSandstorm = Meteor.settings && Meteor.settings.public &&
  4. Meteor.settings.public.sandstorm;
  5. if (isSandstorm && Meteor.isServer) {
  6. // In sandstorm we only have one board per sandstorm instance. Since we want
  7. // to keep most of our code unchanged, we simply hard-code a board `_id` and
  8. // redirect the user to this particular board.
  9. const sandstormBoard = {
  10. _id: 'sandstorm',
  11. // XXX Should be shared with the grain instance name.
  12. title: 'Wekan',
  13. slug: 'libreboard',
  14. members: [],
  15. // Board access security is handled by sandstorm, so in our point of view we
  16. // can alway assume that the board is public (unauthorized users won't be
  17. // able to access it anyway).
  18. permission: 'public',
  19. };
  20. // This function should probably be handled by `accounts-sandstorm` but
  21. // apparently meteor-core misses an API to handle that cleanly, cf.
  22. // https://github.com/meteor/meteor/blob/ff783e9a12ffa04af6fd163843a563c9f4bbe8c1/packages/accounts-base/accounts_server.js#L1143
  23. function updateUserAvatar(userId, avatarUrl) {
  24. Users.update(userId, {
  25. $set: {
  26. 'profile.avatarUrl': avatarUrl,
  27. },
  28. });
  29. }
  30. function updateUserPermissions(userId, permissions) {
  31. const isActive = permissions.indexOf('participate') > -1;
  32. const isAdmin = permissions.indexOf('configure') > -1;
  33. const permissionDoc = { userId, isActive, isAdmin };
  34. const boardMembers = Boards.findOne(sandstormBoard._id).members;
  35. const memberIndex = _.indexOf(_.pluck(boardMembers, 'userId'), userId);
  36. let modifier;
  37. if (memberIndex > -1)
  38. modifier = { $set: { [`members.${memberIndex}`]: permissionDoc }};
  39. else if (!isActive)
  40. modifier = {};
  41. else
  42. modifier = { $push: { members: permissionDoc }};
  43. Boards.update(sandstormBoard._id, modifier);
  44. }
  45. Picker.route('/', (params, req, res) => {
  46. // Redirect the user to the hard-coded board. On the first launch the user
  47. // will be redirected to the board before its creation. But that's not a
  48. // problem thanks to the reactive board publication. We used to do this
  49. // redirection on the client side but that was sometimes visible on loading,
  50. // and the home page was accessible by pressing the back button of the
  51. // browser, a server-side redirection solves both of these issues.
  52. //
  53. // XXX Maybe sandstorm manifest could provide some kind of "home URL"?
  54. const base = req.headers['x-sandstorm-base-path'];
  55. // XXX If this routing scheme changes, this will break. We should generate
  56. // the location URL using the router, but at the time of writing, the
  57. // it is only accessible on the client.
  58. const path = `/boards/${sandstormBoard._id}/${sandstormBoard.slug}`;
  59. res.writeHead(301, {
  60. Location: base + path,
  61. });
  62. res.end();
  63. // `accounts-sandstorm` populate the Users collection when new users
  64. // accesses the document, but in case a already known user come back, we
  65. // need to update his associated document to match the request HTTP headers
  66. // informations.
  67. const user = Users.findOne({
  68. 'services.sandstorm.id': req.headers['x-sandstorm-user-id'],
  69. });
  70. if (user) {
  71. const userId = user._id;
  72. const avatarUrl = req.headers['x-sandstorm-user-picture'];
  73. const permissions = req.headers['x-sandstorm-permissions'].split(',') || [];
  74. // XXX The user may also change his name, we should handle it.
  75. updateUserAvatar(userId, avatarUrl);
  76. updateUserPermissions(userId, permissions);
  77. }
  78. });
  79. // On the first launch of the instance a user is automatically created thanks
  80. // to the `accounts-sandstorm` package. After its creation we insert the
  81. // unique board document. Note that when the `Users.after.insert` hook is
  82. // called, the user is inserted into the database but not connected. So
  83. // despite the appearances `userId` is null in this block.
  84. Users.after.insert((userId, doc) => {
  85. if (!Boards.findOne(sandstormBoard._id)) {
  86. Boards.insert(sandstormBoard, {validate: false});
  87. Activities.update(
  88. { activityTypeId: sandstormBoard._id },
  89. { $set: { userId: doc._id }}
  90. );
  91. }
  92. updateUserPermissions(doc._id, doc.services.sandstorm.permissions);
  93. });
  94. }
  95. if (isSandstorm && Meteor.isClient) {
  96. // XXX Hack. `Meteor.absoluteUrl` doesn't work in Sandstorm, since every
  97. // session has a different URL whereas Meteor computes absoluteUrl based on
  98. // the ROOT_URL environment variable. So we overwrite this function on a
  99. // sandstorm client to return relative paths instead of absolutes.
  100. const _absoluteUrl = Meteor.absoluteUrl;
  101. const _defaultOptions = Meteor.absoluteUrl.defaultOptions;
  102. Meteor.absoluteUrl = (path, options) => {
  103. const url = _absoluteUrl(path, options);
  104. return url.replace(/^https?:\/\/127\.0\.0\.1:[0-9]{2,5}/, '');
  105. };
  106. Meteor.absoluteUrl.defaultOptions = _defaultOptions;
  107. }
  108. // We use this blaze helper in the UI to hide some templates that does not make
  109. // sense in the context of sandstorm, like board staring, board archiving, user
  110. // name edition, etc.
  111. Blaze.registerHelper('isSandstorm', isSandstorm);