For the mobile application to run in Flutter, I made user login, listing, adding, deleting etc. operations via database connection via Json web service.
One of them is the login process. The username and password values are given as parameters and the process works in the post method. This is not visible on the link on the url and is spinning in the background, but
When you look at the Windows Server IIS site logs, it says login?username=abcd&password=1234 as in the image below, because the full address of each visited page is written.
The red place in the image is the time, the blue place is the fixed ip address, the green place is the page name, the orange place is the external ip address visiting the site, that is, the web service.
Yes it's my server, it's my data and no one else can see it but what can I do to make it not so obvious and security?
Regards..
Log path file; C:\inetpub\logs\LogFiles\
Related
I am currently building a Chrome extension that lets users auto-register for courses on a particular website once registration opens. The registration process is just a simple fetch POST request with an authentication header.
Now, this already works using the chrome.alarms API while the browser is open, but for obvious reasons I would want this to also work once the user closes the browser. Do you have any ideas how to do this? I really want to avoid to externally save user data..
If this is impossible, my idea would be to send the registration fetch to an external server (maybe even one hosted on a Raspberry Pi? Other ideas?) and then execute it once the registration opens.
Images are stored in an ftp server ,even they are present at the path, not displaying sometimes(first request/ refresh). I used the below code to specify the path :
<img src=" ftp://username:password#ip.ad.dr.ess/arunsimages/wall_X24JUmm.jpg"
but try to open the path in browser ,will display the image
Just as mplungjan mentioned above, you do not want to serve up an image via FTP in your HTML code. Anyone visiting your page can view the source and grab your username and password. Even if that user login is a read only privileged user, it is still a bad idea.
The IP address in your question resolves to a Net4 hosting account. The hosting provider most likely only allows one instance of that FTP login at a time. Which means the first person to visit your page will see the image, but until that person ends their session, the next visitor will not be able to view the image.
I strongly suggest you contact Net4 and disable that FTP username and password and create a new FTP username and password. If I was able to locate the page that contained the actual username and password because you had the actual IP address in the question, then most likely someone else already has or will once they see this question.
Have a Net4 hosting customer service representative assist you in how to correctly serve up an image with their services.
I have a REST api written in node which uses HATEOAS. The user is required to have an account before they can access the bulk of it.
They register an account with login details, then login to obtain an access token, and then use that token in order to access any endpoints that aren't register or login.
Issuing a get to the root responds with a directory with available actions.
Q: What is the correct response from register, to tell the client what it can do next (i.e. login)?
register technically creates a new resource on the server so a 201 CREATED and a Location header would seem appopriate. However the login reference isn't the location of the newly created resource.
Should I return 201 Created with a Location pointing to the newly created user (e.g. /myaccount or /users/{id} and then include a login link in the response body?
{
_links: {
self: { href: "what goes here?" },
x:login: { href: "/login" }
}
}
Do I not tell the client at all, and require them to do a get on the application root in order to fetch a list of available endpoints. This should include login anyway. Assuming the client had to do that in the first place to get the register link it should already have login.
Expecting the client already to already have the login link feels uncomfortable as it relies on an assumption of the client's prior activity.
Requiring the client to issue another request to the root directory after registering seems mean, inefficient and unnecessary. If the client has just created a resource it seems only fair that the server should respond with what it can do with it next.
I like to have my api's act no differently than a webpage. If you want the UX of your application to be the user is taken to login after they register, then 302 them from a successful register to the login resource. And upon successful login, 302 to them to the appropriate destination (IE, if they tried to access something with no token, then take them to login, with a destination of the original requested resource). That's and important part to your #3. Having a link off the root that leads to login, but you need to protect all the other links such that they indicate (and link to) a login being required to access the resource. The client app should expect to get this login required response at any time as tokens can (and do) expire at any time.
Following on this, it might make sense to do the JWT as a cookie instead of as an Authorization Header, it would make it a bit easier for the client (they just have to setup a cookie jar)..if the client is say a native mobile app that maintains a single connection setup. If it's server to server, then auth header makes sense. I'd go about supporting both to cover both scenarios.
Continuing on the idea of thinking of the api as a web site. Why have them login after registration at all? Why not have the registering of an account end up with the login token being sent? they just set their user/pass, why make them enter it again? I realize with some more exotic architectures the register service can not perform the login action (perhaps it doesn't have the private key to sign the token), but if it is possible i'd consider it.
If you really want to stick to the 201 header (which is fine, just make sure the docs of your register relationship indicate that), then option 2 is the closest in my opinion. A location header to the URL of the account just created a 201 is pretty standard for creating a user. But, i'd not return what you've supposed there. You're kind of returning a account-created resource (the thing with the login link), but do you really need this custom resource? If you want to give some messaging back to the client (like "Account Created") in that resource then absolutely yes, but you could also just give them back the root resource.
tl;dr; Decide what you want your UX to be and then make your API implement your UX.
I would like to create a web application where a user can drag and drop images and text onto a div or similar container. Then, when the user clicks a save button, the application would be able to save the content of the dropped items, as well as the positional information for those items.
Ultimately the user should be able to come back, open then application, and have the images and text back in the exact same places as when they were saved.
If anyone knows a methodology or framework that could assist in accomplishing this, it would be appreciated.
When the user hits the save button, you will need to collect the dynamic state of the current web page (which sounds like images and positions) and send that to your server with some sort of user id that uniquely and securely identifies this user. The next time that user loads this web page, you can either put the state into the web page as it is retrieved from the server or you can use client-side javascript to retrieve that user's state from the server and then dynamically modify the page to match the desired state.
You can save the state to the server with either an ajax call or a post. You can retrieve the state from the server from the client javascript using an ajax call or if the state was already put into the web page by the server, you can just refer to it there.
This is somewhat of a newbie question I'm sure and I hope the community will excuse me for not knowing this (or not knowing the appropriate search terms to resolve my question).
So, this is the deal: I'm running a small webpage with a small amount of visitors. I've written the whole page in HTML and CSS myself and I host it in my private DropBox (http://dl.dropbox.com/u/3394117/Hemsida/Psykofil/Index.html).
I've bought the domain name "www.psykofil.org" from Loopia (www.loopia.se) and I've directed this domain to the index.html file referenced to above.
Now, this is what I want to happen: I have three different places you can go to on the page (you choose where to ge through a menu on the left). When one of these links is clicked, it takes the user to another .html-file. What I would like to happen here is that this is seen in the adress field so when he or she clicks on "x", it should say www.psykofil.org/x on top. Also, when he or she navigates away from the webpage through a hyperlink I would like the adress field to update to show the new location. Right now, no matter what the user does, it always says www.psykofil.org in the adress field.
I probably should mention that my options (freely translated from swedish) when I go to the configuration of my domain name at Loopia is the following:
DNS
Parking
Forwarding (the one I'm currently using)
Send to an external URL
(Unavailable because I don't have a web hotel with Loopia) Point to another domain in the account.
(Unavailable because I don't have a web hotel with Loopia) Own homefolder for webpage.
That's because your page is inside a <frameset>, so the address bar will never update.
You say "I've directed this domain to the index.html file referenced to above." It sounds like you've set up 'domain forwarding.' Framesets are often the 'trick' hosts use to keep the same URL - embedding the pages you're 'forwarding' to in a frameset. It's called "domain masking." See http://www.hostingmultipledomainnames.com/domainforwarding.htm for a description of how it works.
If you upload your actual html files to your site root, that should do the trick. If you're not sure how to do that and you're a new webmaster, you may want to be in touch with your web host's support. Otherwise, if you want to have that domain, but keep your files in your dropbox account, your options I believe get complicated (things like reverse proxies).
UPDATED:
Typically, when people create a website, they do three thing: register a domain, buy a web hosting account, and then associate their domain with their hosting account. You've done the first part, and have found a clever way of managing the second part, but you haven't done the third part.
The process is like this:
You register your domain. I.e., you pay $10-30 a year for the exclusive right to a given domain name. Registering the domain means that when people type 'http://mysite.com' into their browser, your domain will come up. However, it's just a placeholder - there isn't any real content there. All your files and images need to be uploaded to a server in order for people to see them.
You purchase a web hosting account. Or in your case, you upload your files to a publicly-accessible server, which has the advantage of being free. You then upload all your content.
This is the part you're missing. You now need to associate your domain name with your hosting account. This typically happens without your intervention when you purchase both your domain name and your web hosting account through one company.
However, if you acquire them separately, you need to do two things:
a. Log in to your domain registrar and point the domain name to your server for your web hosting account. This is a signal to the Internet - hey, when you type in the domain name 'http://ssss.com', go to this server.
b. Log in to your web hosting account and "park" the domain at your account. This may be hard to understand at first, but basically, just telling the Internet to go to this or that server when typing in your domain name isn't very useful.
If that's all we needed to do, I could just register http://my-amazon.com and point my domain to Amazon.com. Then people could surf Amazon.com as http://myamazon.com and I could get rich from selling this now incredibly popular domain.
But that doesn't work. In order for me to actually browse the web hosting account through my domain name, I need to "add" the domain name to my hosting account. Dropbox doesn't let you do that. It's a file-sharing system, which you've cleverly used as a web host. However, you'll never be able to log into Dropbox and park your domain there, because that's not what they do.
Summary: You can think of this process like a pass in basketball. You can throw the ball by sending the user to a server, but the server has to catch it. In order to catch the ball, the server needs to know it's coming.
Your domain registrar is 'faking' this process by adding one page to its own server, which links to "http://dl.dropbox.com/yourpage/etc/etc/Index.html". This way, your domain registrar doesn't have to worry about hosting all your content and the headaches of technical support and server space.
The downside is, you don't have a webhost that allows you to park a domain at the moment. The upside is you're saving about $60-100 per year (it might be more or less in Sweden), which is what a basic "shared" hosting account would cost.
You can decide if having distinct webpages (http://psykofil.org/contact.html" etc), is worth it for you, or whether you're fine for now with the very low-cost solution that isn't perfect but at least allows people to access your site. What you've come up with is actually pretty cool, but it does have some limitations.
Finally: If you do want to go ahead an buy server space so you can host your site, it will be less of a headache to buy it through Loopla, if the price and service are good. Typically, you are given the option when making the purchase of linking your account to your already-registered domain name. Then all you need to do is use an FTP program like Filezilla to upload your content to your account, and you're done.
It seems your host is "masking" the URL, meaning actual index.html page located at "www.psykofil.org" is in fact, loading your index page located via dropbox into an "iframe" , hence your main URL does not change to reflect the changes.
Solution: Upload your file to your main host and change the default index file that has iframes with the dropbox index file.
I believe it's because you're using frames. Were you to simply link to the other html page(i.e About page) then the address bar would update.