I was wondering if I could use PHP to do SSO between two different sub-domains. (ex: parappawithfries.com and *.parappawithfries.com). My config is not like it should be, because I use cloudflare to point my subs to a different 000webhost website. I know I should just use infinityfree, but I don't get https:// and subdomains. Lots of issues, but it it could be fixed, that'd be great. ANYWAY, I was wondering if I could do something like this in HTML.
<script src="https://parappawithfries.com/user.js"></script>
and in user.js (in the NON sub-domain) needs to set a cookie with the user's PHPSESSID copied over by JS by basically printing it as a variable. Can I do that with JS, AJAX, jQuery, or any way possible without using anything other than PHP, HTML, JS, AJAX, or jQuery?
Ok, ok lemme edit im sorry.
parappawithfries.com points to parappawithfries.000webhostapp.com.
It's subdomains don't point to a folder in parappawithfries.000webhostapp.com. it points to a DIFFERENT 000webhost site. Not a folder in parappawithfries.000webhostapp.com.
Oh yeah, btw, here is an example: https://imgur.com/a/giBwTwp
I need to edit... AGAIN (this is getting tiring)
I switched hosting from 000webhost to infinityfree and I got subdomains working. Time to see if it will work now...
In PHP if you setcookie() with a $domain parameter (e.g. parappawithfries.com), that cookie can be accessed by that domain and any subdomains.
https://secure.php.net/manual/en/function.setcookie.php
From there, you can make sure all your sites are set up to used a singular Memcached server, and they should all be able to share the same session(s).
Have a look at the below link for some details on setting this up.
https://www.digitalocean.com/community/tutorials/how-to-share-php-sessions-on-multiple-memcached-servers-on-ubuntu-14-04
Cookies cannot be shared across different domains; however, you could make use of another domain that would have the cookies and the authentication could take place there.
Related
Good afternoon,
I have a problem that I would like to get your help with if it were possible.
First of all I would like to mention that I am using Angular with TypeScript.
I am trying to make a kind of single sign on of several websites in a single application and I am having some problems when it comes to redirecting to the desired website.
All websites that I am trying to sign in cannot be changed and I can only make changes to the application I am developing.
On the client side, I make a request to the API (NodeJS) that performs the authentication on the intended website and returns an authentication cookie to the client.
So far so good, it's working perfectly. The problem arises when I need to open a new browser tab and pass the authentication cookie I received.
When opening a new tab I am forwarding to the page after login and I need the cookie for that task.
I tried to set the cookie in the browser to a different domain but without success.
Can someone help me, whether it is trying to find a solution or indicating a possible different way to solve the problem?
I would like to mention that the domain of all websites are different from each other and different from the application I am developing.
Thank you in advance to anyone who can help or direct me to the solution and I apologize if I did not understand perfectly what I want. Any doubts tell me that I try to explain better.
Regards,
André Pinto
From frontend you cannot set a cookie of another domain, but what you can do is to have a php page, which sets cookie of another domain or have a backend redirect. you can use this article for detailed information :-
https://subinsb.com/set-same-cookie-on-different-domains/
On reference link more :- Setting cookie for different domain from javascript
As mentioned above you won't be able to achieve this with cookies; being able to set cookies for other domains would be a massive security issue.
If you control the other website and have access to the backend, then your backend can handshake to identify the user. Otherwise you could look at using a querystring redirection to authenticate the user.
All the best.
Suppose I have a JavaScript script named foo.js in a GitHub repo. I need to know what sites (domains) are using this script. Thus, for instance, if a website www.example.com is referencing my script...
<html>
<head>
<script src="https://myGitHubRepo/foo.js"></script>
</head>
etc...
</html>
I'd like to get, track or list example.com as a domain. To be more clear, I don't want to track actual users visiting www.example.com nor their IPs nor anything like this, I just want to track or make a list of the sites (domains) referencing my script in their HTMLs. Is that possible?
PS: some hypothetical solutions and their problems:
The first idea that comes to mind is using an analytics tool; however, despite being the owner of my code, I'm not the owner of the site containing the repo: GitHub is the owner. Therefore, using an analytics tools seems to be impossible.
I can't do calls to my server: again, I don't have a server, it's a GitHub repo.
A simple window.location.hostname in the script would get what I want, but it would get it on the client side. I don't know if it's possible sending that information back to me... actually, I don't even know if that is legal.
Don't do it. Telemetry is tricky - and people will opt to not use your script.
Also without "place" to gather this information you cannot do it on github.
You can try leveraging "code" search engines like:
https://publicwww.com/
https://www.nerdydata.com/
and similars
Without addressing the legal aspect, you could embed PAT (Personal Access Key) in your script, which would enable said script to make GitHub API calls.
Typically: "Create or update a file (PUT /repos/:owner/:repo/contents/:path)" (I mentioned it here)
You would replace the content of a file in a dedicated user/repository with the domain name you get from the script.
Each version of that file would represent one instance of the script execution, with the associated domain written in it.
The drawback is that anyone could use that key for accessing the repository, so you need to monitor its content and usage carefully (again, using a dedicated user account/repository just for that one usage).
As noted below by bk2204, this is too insecure.
Instead of a PAT, you can adopt a similar workflow as a GitHub webhook: your script would call a dedicate URL, with a JSON event, which would then register the call.
In a static web app (nothing except html, css and javascript),
I'm searching for a method to protect a file (e.g. json) from being accessed.
That file should only be accessible by authenticated and approved users. (I don't know yet how authentication will be handled.)
I can hide the view of the content in the application with userapp.io e.g., but I can't prevent someone to read it if he wanted to.
Would this be possible?
I thought of putting the protected file on www.firebase.com, but I could not find any practical example.
I also found solutions with .htaccess, but I need to avoid server dependent solutions.
P.S.: Not asking for code here ;-), just advice to point me in the right direction will do.
Thanks in advance!
You can limit access through the web server (.htaccess), server-side code, or a third party solution. If you want to keep your app static and want to avoid modifying .htaccess, then your best bet is to find a third party file host that offers authentication. Would something like Box work for you?
If you're interested in putting your website on something like Weebly, then you can password protect certain pages.
In my app, I will provide my client a javascript plugin, which will collect some HTML data and send to my server. I wonder what's the best way to identify my client. Say someone copied the javascript and put into his website. A similar case is the live chat plugin.
Really your questions it is not very clear to me. I am monitoring it from the beginning, so as no one answers I can say the following:
1.- If your javascript plugin is to plug in websites, as a jquery plugin, then you don't be sure about nothing because the code can easily be modified to remove any security procedure.
2.- If your javascript plugin is to plug in browsers, as a FF addon. Well, indeed can be modified too, but in the most of cases you can track simply with cookies or a login procedure.
Said that I think that if the case is the first (plug in websites) you could identify the websites asking for a authentication token stored in the server's website (requested by AJAX) and add it to the HTML data that is send to your server.
Hopefully you can understand my Emglizch :) and do not say pure garbage.
I need to figure out the best way to determine if someone is the actual owner of a website. I don't just mean the domain although in a lot of cases that might be the case.
My first inclination was to have them put a special comment in their HTML that my program can scrape. e.g.:
<!-- #webcode:1234 -->
One possible problem with that approach is someone in theory could add it in the comments on their page or some other way to add content. Although I'm not sure anything I have them do couldn't be gotten that way.
My other idea was since I was planning on also offering a JavaScript widget was to just scrape that although I didn't want to necessarily force them to add the widget.
<script type="text/javascript" src="http://yoursite.com/widget/widget/A4923D2342JF"></script>
What other mechanisms could be employed to determine ownership/control of a website?
Here are the options that Google uses for Domain verification:
Create a CNAME or TXT record in your
domain's DNS settings. These methods
require accessing DNS settings for
your domain at your domain host's
website. Which method you can choose
(CNAME or TXT record) depends on
what's offered in your Google Apps
control panel. We're currently
rolling out the TXT record method but
still ask many customers to create a
CNAME record, instead.
Upload an HTML file to your domain's
web server This method requires being
able to upload files to your domain's
web server. Try doing this if you
don't have access to your domain's
DNS settings.
Add a tag to your home page
This method is available only for
some customers (it's another new
method we're rolling out). It
requires accessing your domain's web
server but not uploading to it. Try
doing this if you have write access
to files on the server but can't
upload new files.
CNAME/TXT or uploading an HTML file to the root of the domain is the most secure, since it requires full control of the domain. If you want to be a bit more lax you could use a Meta tag in the head node, which would prevent someone from adding a comment to a page. All depends on how secure you want to be.
Do what Google does for their Webmaster Tools. Generate a unique key, and have them put it in a meta tag in the head of their front page. It's pretty unlikely that a user who does not own the site will be able to change the contents within the <head></head> tags. If they can, the site is vulnerable to almost any kind of vandalism, and is hopeless.
You could have them add your original idea but only accept the comment in, say, the <header> tag of the website. This way you could avoid having them past the comment into a 'comments' section like you originally suggested.
In fact, I subscribed to a service that did just that: include the special comment in the header section of your page.
Make part of the requirement be that comment be inside of the <head> tag. Typically, even user generated content wouldn't make it's way into the head.
Also, your concern about the comment hack are probably unnecessary. Any comment system worth it's weight knows to escape comments so that the comment is not displayed as actual HTML markup.
Have them put a file with a hard to guess name on the server?
such as http://www.example.com/5gdbadcab234g3.txt
The only true way is to be able to access their fileserver. Anything transferred through HTTP can be reproduced.
If you don't have access to their server, then the best way would be to have an encrypted string embedded on the page (or in an image or some binary file on that page).
The string should be comprised of the URI, author, and timestamp. That way, even if someone does copy this string to their website, you would still be able to determine the author and the page. An added bonus is you'll be able to determine if there was a theft.
Granted, this is only as good as the algorithm that encrypts the page/author combination; hackers that are good at decrypting could get around this. Additionally, a dishonest author could create his own key for his page, thus you'd need to host the encryption so that no one could tinker with the timestamp. Also, this requires that all authors places the code on their page.
I know you mentioned that it isn't necessarily domain dependent but that would help. You could hash the domain (as they are unique) and send the person that string to put somewhere on their site either .txt or in the header as others have mentioned.
Then you store all their domains and their hashes in a database and your scraper would check that the domain it is scraping matches the hashed comment string, if it checks out then its fine.