I'm using angular-meteor to write a multi-tenant app, so I'm not using Iron router. I would like to be able to get the subdomain that the user is accessing the page from within a collection hook. (I am using the separate collection hooks package) This parameter will only be used if a trusted superadmin is accessing the page over SSL so it will be trusted input. I just can't for the life of me figure out how to get this. I tried using this.connection.httpHeaders, however, this only works in publish and meteor subscribe methods. It must be so simple, but I just can't figure it out. I'm asking here, because there is probably someone who knows much better than I and could point it out in a second.
Related
I am making a web app using firebase. I was looking into restricting access to certain pages unless there's a subscription. When I looked through the docs all I found was that I could do transactions with stripe and it only applied on signing in and up not restricting pages.
After searching on the internet, I didn't find a viable solution, but three ideas came up to me I could use (which are either with low working possibility or very lackluster to say the least. (all include using stripe.))
One: I would use a middleware to verify the token I get from stripe and then redirect from there. (but all that comes to my mind how I would identify the redirected page in the middleware. And even if that was probable how much time would that take to make it work(if that even is possible), I have no idea.)
Two: in hosting configurations I could call a function when a rewrite is performed. I thought I could call a make a function that verifies the token from the strip when a restricted page is called. (But then again not only is the function accessible after hosting and can be viewed, I don't know if I can call firebase configurations and functions inside the firebase.json.)
third: this is the most viable but has very bad downsides, is authenticating the strip token from in a regular javascript, and if it fails it would restrict the access to the page. Do the same in the rules so that the database section related to that page. (the downside is that the HTML, CSS, and javascript would all be accessible. Only the database functions relating to them are restricted.
So with all that being said, I couldn't find any viable option I could use. So I was wondering if anyone in here have met the same problem and got a solution or do you have any advice I could use.
Note: I am using firebase's realtime database by the way.
If you are trying to restrict access to your webpages/app, you should come up with a logic in your backend or frontend (depending on your app structure) where you could store values needed in Firestore or another solution.
In case you would like to restrict access to Firestore, you can achieve that with Rules.
It's unclear for me and I haven't attempted yet, but would like to know if I can have a NGINX server routing traffic to a Firebase instance. I can't find relevant articles on internet and neither here so, maybe some fo you already tried this.
Background:
Our React app is running on Firebase already. But, we also have a landing page/website which is backed by Webflow.io to allow quicker edits with less developer frustration. They are also running on separate domains.
We already have an instance of NGINX(inside a docker container) as part of our API gateway so, would be good to use the same instance.
Result:
What we are looking to achieve, is to put both React app and landing page on the same domain. Then, use NGINX to route to required instance wether the user is logged-in or not. Anyone attempted something like this? If not this doesn't work, I'm open to general ideas on how to make it better from your experience.
You can totally do this, for example if you're using OAuth you can perform a token introspection from nginx whose result will determine the route to use, take a look at this https://www.nginx.com/blog/validating-oauth-2-0-access-tokens-nginx/
Alternatively you can use something similar to the google IAP that is probabely more easy to secure for production, i know that ory/oauthkeeper is easy to use, open source and hightly customizable.
The Conduit API in Phabricator does not support setting of authorPHID parameter while calling maniphest.createtask. I can imagine this is because of security or some logical reason.
But I am developping my own frontend for Maniphest where the users (logged through Phabricator, so they are phab users and have phid) will add and edit tasks. What I need is that if a user creates task, he is also the author of the task.
But the problem is, that I can't connect to Conduit as any other user than "apibot" because I don't have others certificates in my front-end to do it. But if I log in as "apibot", then "apibot" is set as an author of the task.
Three possible solutions came to my mind:
1. retrieve certificate directly from phab's database
2. keep a list of certificates in some file in my front-end and update it manually everytime somebody will register
I guess none of them are really smart...
The third solution would be nice, but I didn't find a way, how to do it:
3. log in as "apibot", get certificate of userXY and then log in as the userXY
What would you suggest?
I really need some expert help here!. Does anybody knows of a way of getting the list of the users currently connected to a BlazeDS server? Is there any built-in mechanism of knowing this? or do I have to implement some kind of server side logic every time a user access my Flex application and store all logged in users details somewhere and retrieve them later?
The nearest thing I can think of, using BlazeDS, is to obtain a list of clients currently subscribed to a destination, but this won't solve the problem IMO.
First of all, you need to define a destination and make sure that all clients will actually subscribe to it (see BlazeDS documentation for this). Then, on the server, you can then get a reference to the message service
MessageService messageService;
messageService = (MessageService) messageBroker.getService("message-service");
and ask for all subscribers with the getSubscribersIds method on the MessageService instance, specifying the name of your destination. This will only returns a number of identifiers, internally generated by BlazeDS (they are also available on the client side of the connection).
To resolve the same problem, I used this approach in combination to a custom server-side logic to store logged-in users (explicitly invoked login/logout methods). Regularly looking at the subscribers can help to clean this store, because in my experience there's no way to be sure that a "logout" method will always successfully called, expecially from Flex client running in the browser, while BlazeDS will automatically take care of cleanup of the subscribers.
I don't like very much this approach, probably someone came up with a better solution..
I am using DotNetOpenAuth in my ASP.Net Website. I have modified it to work with Facebook Connect as well, using the same methods and database structures. Now I have come across a problem.
I have added a Facebook Connect button to a login page. From that HTML button, I have to somehow pull information from the Facebook Connect connection and pass it into a method to authenticate the user. The way I am currently doing this is by:
Calling a Javascript Function on the onlogin function of the FBML/HTML Facebook Connect button.
The javascript function calls a Web service to login, which it does correctly.
The web service calls my data access layer to login.
And here is the problem: FormsAuthentication.SetAuthCookie is set at the data access layer. The Cookie is beyond the scope of the user's page and therefore is not set in the browser.
This means that the user is authenticated, but the user's browser is never notified.
So, I need to figure out if this is a bad way of doing what I need or if there is a better way to accomplish what I need. I am just not sure and have been trying to find answers for hours. Any help you have would be great.
Yes, it sounds like you are having a design crisis brought on by trying to do too much at one time/in one place.
If you break this operation up in to two calls from the client you will find your options opening up quite a bit. It might take some more work but ultimately the code will be less complex. <-- a good thing.
And in my opinion, the first clue pointing to a crisis of design would be when I said to myself "Self, having an authentication method buried two calls deep in my DAL is not working the way I would like...." lol.... I am joking and serious same time.
Good luck.